<div dir="ltr">Not quite sure if it fits your use case, but we use a technique at work basically as described in the following:<div><br></div><div><a href="https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run">https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run</a></div><div><br></div><div>Your case sounds more complicated, but maybe the above technique might help if you can organise things that way.<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 11, 2018 at 10:54 PM, Settenvini, Matteo <span dir="ltr"><<a href="mailto:matteo.settenvini@here.com" target="_blank">matteo.settenvini@here.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
I have the following problem which I don't know how to best solve.<br>
Any help is appreciated.<br>
<br>
============== Use Case ==============<br>
<br>
Consider the following use case:<br>
<br>
* We are cross-compiling.<br>
* A certain project A depends on project B in two different ways:<br>
  - it uses an executable target from B to generate some files, e.g. a compiler.<br>
  - one of its libraries links against a library of B.<br>
<br>
We would like to be able to do (not possible with CMake at the moment):<br>
<br>
<br>
  find_package(B REQUIRED)<br>
  # use B::lib normally. When crosscompiling, it will be the one compiled for the target.<br>
<br>
  find_package(B REQUIRED NO_CMAKE_FIND_ROOT_PATH)<br>
  # use B::exe knowing that it will always run from the host system.<br>
<br>
<br>
This is for instance a use case we have for flatbuffers / protobuf.<br>
<br>
IMPORTED and ALIAS targets should not be global, or it should be<br>
possible to override them. Or else, it should be possible to<br>
dynamically specify a namespace when importing targets through<br>
find_package().<br>
<br>
I opened a bug at <a href="https://gitlab.kitware.com/cmake/cmake/issues/18169" rel="noreferrer" target="_blank">https://gitlab.kitware.com/<wbr>cmake/cmake/issues/18169</a>,<br>
but it got closed as there are no plans to change the way CMake works.<br>
<br>
The issue contains also a test case, if you'd like to try it out.<br>
<br>
============== Problem ==============<br>
<br>
The user cannot import a project twice to get the appropriate targets<br>
when cross-compiling: once for the host architecture and once for the<br>
target architecture.<br>
<br>
Right now, the user needs to manually use e.g. find_program() instead<br>
of relying on installed locations, which can be annoying if the<br>
binaries are installed outside the environment PATH. This can be<br>
worked around, but we would like to use targets in place of<br>
find_program() or find_library() calls.<br>
<br>
The problem is much more apparent in big superbuilds where you have<br>
hundreds of projects brought together in one build and no control over<br>
components outside your own. It is too hard to ensure a stable<br>
configuration order (so that find_package() is always called for the<br>
host version before the target version, or vice-versa).<br>
<br>
============== Help needed ==============<br>
<br>
How would you solve the issue, so that different targets are available<br>
for both the version built for the host and target architectures?<br>
<br>
Note that sometimes these external projects are not under our control,<br>
and they come directly from upstream as git submodules. So we would<br>
like to touch them as little as possible.<br>
<br>
Bests,<br>
Matteo Settenvini<br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/<wbr>CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" target="_blank">https://cmake.org/mailman/<wbr>listinfo/cmake</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div></div></div></div></div></div></div>
</div>