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.ba...@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 -- 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