Thanks Craig,
we are already doing roughly that, plus some custom logic we built around options to be able to forward them to the second CMake process. It's a bit more complex for us, but the concepts are the same. The problem is just being able to use targets for the version of the executables compiled for the host, instead of using find_program or hardcoding paths like you do at step (e) in your StackOverflow answer. It wouldn't be that important if all people using our internal CMake API were also CMake experts, but unfortunately we have lots of baffled developers by having to call "find_program()" and then variables, instead of "find_package(pkg REQUIRED NO_CMAKE_FIND_ROOT_PATH)" and then use an imported target. Also, this is asymmetrical when non-crosscompiling, which adds more logic than necessary in several places. Cheers, Matteo Settenvini ________________________________ From: Craig Scott <craig.sc...@crascit.com> Sent: Thursday, July 12, 2018 12:00:18 AM To: Settenvini, Matteo Cc: cmake@cmake.org Subject: Re: [CMake] Cannot import a project twice when cross compiling (as host-tool and for the target arch) Not quite sure if it fits your use case, but we use a technique at work basically as described in the following: https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F36084785%2Fbuilding-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=xJ%2FHdGlj4O%2FRulWQNQY6nWhpodk3sBpiDM6EucQJXZk%3D&reserved=0> Your case sounds more complicated, but maybe the above technique might help if you can organise things that way. On Wed, Jul 11, 2018 at 10:54 PM, Settenvini, Matteo <matteo.settenv...@here.com<mailto:matteo.settenv...@here.com>> wrote: Dear all, I have the following problem which I don't know how to best solve. Any help is appreciated. ============== Use Case ============== Consider the following use case: * We are cross-compiling. * A certain project A depends on project B in two different ways: - it uses an executable target from B to generate some files, e.g. a compiler. - one of its libraries links against a library of B. We would like to be able to do (not possible with CMake at the moment): find_package(B REQUIRED) # use B::lib normally. When crosscompiling, it will be the one compiled for the target. find_package(B REQUIRED NO_CMAKE_FIND_ROOT_PATH) # use B::exe knowing that it will always run from the host system. This is for instance a use case we have for flatbuffers / protobuf. IMPORTED and ALIAS targets should not be global, or it should be possible to override them. Or else, it should be possible to dynamically specify a namespace when importing targets through find_package(). I opened a bug at https://gitlab.kitware.com/cmake/cmake/issues/18169<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fcmake%2Fcmake%2Fissues%2F18169&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=O2F%2BX4iOCnF7HYxPFBkSobsrqxkyTIhkcFJ3fjeP81k%3D&reserved=0>, but it got closed as there are no plans to change the way CMake works. The issue contains also a test case, if you'd like to try it out. ============== Problem ============== The user cannot import a project twice to get the appropriate targets when cross-compiling: once for the host architecture and once for the target architecture. Right now, the user needs to manually use e.g. find_program() instead of relying on installed locations, which can be annoying if the binaries are installed outside the environment PATH. This can be worked around, but we would like to use targets in place of find_program() or find_library() calls. The problem is much more apparent in big superbuilds where you have hundreds of projects brought together in one build and no control over components outside your own. It is too hard to ensure a stable configuration order (so that find_package() is always called for the host version before the target version, or vice-versa). ============== Help needed ============== How would you solve the issue, so that different targets are available for both the version built for the host and target architectures? Note that sometimes these external projects are not under our control, and they come directly from upstream as git submodules. So we would like to touch them as little as possible. Bests, Matteo Settenvini -- Powered by www.kitware.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=Kii%2Bk7gLL8hCJ1ekpXIKmzjgSU1Gu76eciezF1YX8Yw%3D&reserved=0> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cmake.org%2FWiki%2FCMake_FAQ&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=VEtz1dYyQ3I82TmCoFiKFodBsgpirKbi6fHL9TePiGc%3D&reserved=0> 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<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fsupport.html&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=vPD2YmT%2FnYsPmE7qZgv7jJVWyZu%2FtyzbGREeajdz8HM%3D&reserved=0> CMake Consulting: http://cmake.org/cmake/help/consulting.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Fconsulting.html&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=WswwDS4Qm2H4%2ByA1xn5QyqZFoEaQmqXAw2lOEk1gC5Q%3D&reserved=0> CMake Training Courses: http://cmake.org/cmake/help/training.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2Fcmake%2Fhelp%2Ftraining.html&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=ZGAGTZ33EWW3H5ZPxC1iYekX0NSJJwIWXmR0ewrzUgE%3D&reserved=0> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=jEPvMIis0QoqujH%2BAJ%2F8enyVInFAFAkDl%2FVw4QYJI2k%3D&reserved=0> Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmake&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=WeNcJxyEZQw8kw2ifdsDbW6uVBlNVSs2pmV%2BieHstnY%3D&reserved=0> -- Craig Scott Melbourne, Australia https://crascit.com<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrascit.com&data=01%7C01%7C%7C19358ac4692f4ef2cce208d5e779b1f5%7C6d4034cd72254f72b85391feaea64919%7C1&sdata=HZ7nPd1P%2Fgd8SrsysnKG%2BHa5sxd1H5BDJWfiqt%2FJvNg%3D&reserved=0>
-- 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
