I guess what I would ultimately like to achieve would be a "pre-cmake-configuration" step that just initializes the package registry with the location of each project's build tree and copies the "project-config.cmake" files into each projects build-tree. This would allow it to be found during generation, but it doesn't seem like it works that way. Maybe some sort of "superbuild" pattern would be a better option.
On Thu, Feb 14, 2019 at 1:32 PM Eric Noulard <eric.noul...@gmail.com> wrote: > > > Le jeu. 14 févr. 2019 à 18:57, Timothy Wrona <tjwrona1...@gmail.com> a > écrit : > >> The problem is it is very likely that there are some circular >> dependencies in the build tree -- which is why it was broken up to >> generation of all, then build all, then link all in the first place. >> > > Yes, wrong solution to a real design issue :-) > > >> >> With circular dependencies there's no real way to sort these dependencies >> out without just running generation twice, but the first run will get a >> bunch of errors for missing packages. >> > > I understand the situation, I did face that too in the past. > If there is not too much circular deps you may either break them by > writing (by hand) a bunch of imported target or you can merge in the same > CMake project the sub-projects belonging to the same cycle. > Feasibility depends on the amount of projects (and cycle) you have. > > > > >> >> On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard <eric.noul...@gmail.com> >> wrote: >> >>> >>> >>> Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona <tjwrona1...@gmail.com> a >>> écrit : >>> >>>> I have a collection of interdependent CMake projects (lots of legacy >>>> code) that I want to convert to using CMake targets for linking. The code >>>> is built in such a way that all projects run cmake generation, then all >>>> projects build, then all projects link. >>>> >>>> I would like to export a CMake target from one of the projects and link >>>> to it in another, but the issue is the project I am exporting from runs its >>>> cmake generation AFTER the project I am linking the target in. This causes >>>> "find_package" to fail because the target has not been exported yet, but >>>> realistically the exported target is not needed until link-time. >>>> >>> >>> This heavily depends on the target. Modern CMake target convey compile >>> time information as well like compile flags, include directory etc... >>> >>> Can't you re-order the cmake generation order of your projects? >>> If you [ever] have the graph dependency of your projects you may >>> topologically sort them in order to avoid this issue and superbuild them in >>> appropriate order. >>> >>> >>>> Is there a way to delay "find_package" to not look for the package >>>> until link-time? >>>> >>> >>> I don't think so. >>> >>> >>>> At link-time the package will have been exported already and if >>>> "find_package" was not called until then, it would be found successfully >>>> and the target could be pulled in and linked to. >>>> >>> >>> But the build compile line options used to generate build system files >>> are computed during CMake configuration/generation step. >>> So I don't think what you ask is possible. >>> >>> -- >>> Eric >>> >> > > -- > Eric >
-- 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: https://cmake.org/mailman/listinfo/cmake
