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
