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.

  # 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

I opened a bug at,
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.

Matteo Settenvini

Powered by

Please keep messages on-topic and check the CMake FAQ at:

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support:
CMake Consulting:
CMake Training Courses:

Visit other Kitware open-source projects at

Follow this link to subscribe/unsubscribe:

Reply via email to