[cmake-developers] A CMAKE_EMULATOR variable

Brad King brad.king at kitware.com
Wed Mar 4 12:00:05 EST 2015


>> On 04 Mar 2015, at 17:06, Matt McCormick wrote:
>>
>> Perhaps the name CMAKE_TARGET_SYSTEM_EMULATOR is necessary to resolve
>> the ambiguity.

The name "target" is overloaded.  It usually refers to build targets.
Only in a few places does it refer to a cross-compile target platform.
Since this behavior is activated by CMAKE_CROSSCOMPILING, perhaps it
should be named as such: CMAKE_CROSSCOMPILING_TARGET_LAUNCHER.  However,
I do not think a global setting like this makes sense.  We cannot
unconditionally add the cross-compiling target launcher in front of
all tests.  Some tests may be running host tools.  See below.

We already have variables like

 CMAKE_TRY_COMPILE_CONFIGURATION
 CMAKE_TRY_COMPILE_OSX_ARCHITECTURES

to control behavior of try_compile calls.  One could add a

 CMAKE_TRY_RUN_LAUNCHER

to control try_run.  If set it should be used whether we are cross
compiling or not.  This can be used when cross compiling to get the
proposed behavior for try_run.

Tests are another story.

On 03/04/2015 11:40 AM, Florent Castelli wrote:
> not just about an emulator but a wrapper

Wrapping or launching almost always has to be configurable on a
per-test basis.  Any kind of global setting will always need a local
setting to override it.  That raises the question of which one should
take precedence.  There are too many possible semantics here for
"standard" wrapper interfaces to be defined cleanly IMO.

Wrappers can be added directly in the add_test calls.  In particular
the add_test(NAME) signature makes it easy by allowing one to use
generator expressions to refer to the real executable targets:

  add_test(NAME MyTest COMMAND ${mylauncher} $<TARGET_FILE:MyExe>)

This basic primitive allows projects to configure any semantics they
want.

-Brad



More information about the cmake-developers mailing list