On Wed, Jun 29, 2016 at 3:23 AM, Cfyz <cfyz...@gmail.com> wrote: > On 28 June 2016 at 17:19, Raymond Wan <rwan.w...@gmail.com> wrote: >> I think if I were presented with the same problem as Sven, I'd <...> Or, >> if that wasn't possible, use ExternalProject. >> It's inefficient in terms of disk space, but at least A (assuming A >> depends on B) will be built correctly. > What I'm trying to solve (and what Sven's problem looks very similar to) is > more about keeping the information about dependencies. You've mentioned that > yourself in the linked discussion: the real problem are projects with > complex tree-like dependencies, more than one edge deep. And once those > dependencies become optional and configurable, things break completely. It > is impossible to search for the dependency you don't even know about =(.
I agree that what we're observing is a problem, but I don't think it is that big. There are at least 3 solutions discussed so far: 1) The "ad-hoc" method I first mentioned by setting CMAKE_LIBRARY_OUTPUT_DIRECTORY. 2) ExternalProject which will grab a repository and build it. 3) Some Find_Package () mechanism that will do a search for it. 4) Your option of including *.cmake files that provide the paths [sorry, I might have misunderstood it]. If we have some kind of transitive dependency: A depends on B; B depends on C. Then when we build A, we don't really need to know [in detail] that this transitive dependency exists (*). All the compiler needs to know is where is B and where is C. And if B and C are in the same directory (i.e., a system-level directory), that's fine. Suppose B and C are in two different directories. I don't know if it's common, but often, I see install scripts provide a symbolic link from the system-level directory to where B and C are In Sven's case (sorry to put you on the spot, Sven! :-) ), the 3 options don't work because: 1) Modules are in different source trees. 2) Duplication between users on a super-computer. 3) Too many combinations of Find_Package (). 4) Seems ad-hoc? Though not perfect, either (2) or (3) could solve Sven's problem. For (2), ignore duplication. For (3), how about something like what Find_Boost does? It searches for system-level directories, but you can nudge it by setting an environment variable (i.e., BOOST_ROOT) where it will search first. This means each user will have to set an environment variable (or set it on the command-line of CMake with -D). Hmmmmm, I *think* any of this is fine (for Sven's problem), but if it isn't then perhaps I'm misunderstanding the problem... Ray (*) At least, the order to the archives in target_link_libraries have to be correct. But that is done once by the CMakeLists.txt writer and not something the end user needs to worry about. -- 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
