<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 14 févr. 2019 à 18:57, Timothy Wrona <<a href="mailto:tjwrona1992@gmail.com">tjwrona1992@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div><div>Yes, wrong solution to a real design issue :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>I understand the situation, I did face that too in the past.</div><div>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.</div><div>Feasibility depends on the amount of projects (and cycle) you have.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard <<a href="mailto:eric.noulard@gmail.com" target="_blank">eric.noulard@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona <<a href="mailto:tjwrona1992@gmail.com" target="_blank">tjwrona1992@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div></div></blockquote><div><br></div><div>This heavily depends on the target. Modern CMake target convey compile time information as well like compile flags, include directory etc...</div><div><br></div><div>Can't you re-order the cmake generation order of your projects? </div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Is there a way to delay "find_package" to not look for the package until link-time? </div></div></blockquote><div><br></div><div>I don't think so.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>But the build compile line options used to generate build system files are computed during CMake configuration/generation step.</div><div>So I don't think what you ask is possible.</div><div><br></div></div>-- <br><div dir="ltr" class="gmail-m_-5584095850235212361gmail-m_3781256915852140665gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div></div>