Downloaded projects using ${CMAKE_SOURCE_DIRECTORY} break
Closed this issue · 6 comments
Since projects are downloaded as source, when a project uses ${CMAKE_SOURCE_DIRECTORY} it uses the source directory of the highest level project and disrupts the resulting paths.
Is this a limitation of this approach, or can this be worked around?
If the project you are downloading assumes it is the top level project, then your choices are limited. You could just use ExternalProject in the traditional way and not use DownloadProject at all, but that comes with all the usual baggage of what DownloadProject helps to solve. Another choice is to work out a patch you can apply to the downloaded source to address the issues you see and have patch that applied as part of what DownloadProject does. The PATCH_COMMAND option to ExternalProject is also supported by DownloadProject, so you could experiment with that to apply your patch.
I had never heard of PATCH_COMMAND, but I will be looking into it ASAP. That is just the help I was looking for! I didn't know what (if any) options I had. Thanks!
Just as an FYI, I've lately been experimenting with using PATCH_COMMAND on some real world projects. Unfortunately, we've found it to be a bit problematic. Sometimes CMake seems to forget that it has applied the patch and tries to apply it again, which results in the patch step failing and the build stopping with an error. So far, the scenario that leads to this is still unclear, the most I've been able to characterise it so far is that it only happens occasionally and most probably when the download details change in some way. For now, we've had to disable the patching step (it was a non-critical patch in our case), but obviously it would be nice to have patching working reliably.
Thank you for the heads up. I would love for CMake to handle this natively, I wish they would adopt your code. I appreciate your insight!
Cheers!
I have contributed a much improved version of DownloadProject to CMake and it is now on CMake master (so hopefully should be in the 3.11.0 release when it eventually comes out). It's the new FetchContent module and amongst other things, it addresses the issue discussed here. I suggest you give that a try instead, as I can't really fix this issue with DownloadProject without essentially going down the path that FetchContent does anyway (hence I won't be fixing it here).
Actually, sorry, I realised even FetchContent doesn't fix your original issue (I read back through too quickly). The original issue is one that you can't really solve without patching the downloaded project to make it not use ${CMAKE_SOURCE_DIRECTORY}. You could mirror its repo and create your own branch with the patch applied, but obviously the best solution would be getting it changed in the project itself. That won't help for existing releases, but at least future releases of it would be fine. It's often just a case of substituting ${PROJECT_SOURCE_DIR} instead, or for more complex use of the project() command, explicitly naming the top level project, i.e. ${<PROJECT_NAME>_SOURCE_DIR}.