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

Reply via email to