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