[CMake] How do you handle recursive dependencies in CMake

[Ruslan Baratov]

Hi,

On 30-Jun-16 16:01, Sven Baars wrote:
> 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.
What do you mean by "from inside hunter"? Users have to add 
'hunter_add_package(YourProject)' + 'find_package(YourProject CONFIG 
REQUIRED)' this is true. You want to avoid that?

>   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.
Hunter will download all dependencies automatically. 
YourProjectConfig.cmake should contain all dependencies too so 
'find_package(YourProject CONFIG REQUIRED)' is enough.

>   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
Ruslo

>
> 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