[CMake] How do you handle recursive dependencies in CMake

[Nicholas Braden]

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