[CMake] How do you handle recursive dependencies in CMake

[Sven Baars]

I don't think this is a solution to the problem, since then it seems
like the build will still fail for all our users unless they also build
all their packages from inside hunter. If I wanted it to work just for
myself I could just use hardcoded paths. The problem is that I want a
portable way such that users can build my projects without losing
dependency information. In the current situation they are forced to
copy-paste all of my CMakeLists.txt files and add their own stuff to
that. At least if I follow the guides on the wiki/the advice that I got
so far. That is, unless I misunderstand something, which I hope I do,
but no one pointed that out yet.

Sven

On 06/30/2016 02:41 PM, Nicholas Braden wrote:
> If find_project is not enough, and ExternalProject's only problem is
> build duplication, then I think it makes sense to consider a
> CMake-based dependency manager such as hunter:
> https://github.com/ruslo/hunter
>
>
> On Thu, Jun 30, 2016 at 3:59 AM, Sven Baars <s.baars at rug.nl> wrote:
>> This is a reply to the options that Ray gave. Here I will use the
>> package dependencies C -> B -> A{1,2}:
>>
>> 1)  The "ad-hoc" method I first mentioned by setting
>> CMAKE_LIBRARY_OUTPUT_DIRECTORY.
>>
>> As far as I understand, this would mean that every user of all of the
>> different projects would have to be forced to use this, and would not be
>> allowed to "install" anything anywhere else, which doesn't seem nice.
>>
>> 2)  ExternalProject which will grab a repository and build it.
>>
>> This will not work. One of the projects I use is Trilinos, which has
>> build of around 1GB. I don't want to pull and build that for every
>> project I have. Also the build flags that are used sometimes differ per
>> machine, not per project, so it would be nice if I could build it only
>> once per machine.
>>
>> Also, in a more generalized sense, this would also mean that every
>> project I pull with ExtenalProject should also pull its own dependencies
>> with ExternalProject. So then if every project on my system used CMake,
>> this would mean that I would recursively rebuild my entire system for
>> every project I have. This doesn't seem right.
>>
>> 3)  Some Find_Package () mechanism that will do a search for it.
>>
>> The point I had is that we actually try to use this. However, the
>> find_package does not find all dependencies. And we don't know in
>> package C whether it depends on A1 or A2, because of build flags/CMake
>> checks that were used for project B. So we can't just do a find_package
>> for either A1 or A2, because we don't know which one was used unless we
>> perform all the CMake checks that were done in project B (in some cases
>> 10k+ lines of CMake code).
>>
>> 4)  Your option of including *.cmake files that provide the paths
>> [sorry, I might have misunderstood it].
>>
>> This, so far, is the only option, because then B can tell us that it
>> used A2, not A1. This can just be done by providing absolute paths to
>> the libraries that were used in the compilation of B. But we are looking
>> for a standardized way to do this. I'd prefer to not have a lot of
>> custom code in all of my libraries.
>>
>> Now some more information:
>>
>> On supercomputers it is very common that every library on the system is
>> installed in a different directory. This is so every user can load their
>> own version of the library without breaking the system for others.
>> Therefore, you will never find libraries that are installed in the
>> standard system directories where CMake looks for the libraries. By
>> using PATH you can make it able to find the place where to look for the
>> FoobarConfig.cmake files, which is great when you want to build project
>> B, and this is also done automatically on all supercomputers I work on,
>> but those config files do not contain information on where the actual
>> libraries of project A are when you build project C. I guess Cfyz and me
>> think they should in some standardized way.
>>
>> Sven
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake