[cmake-developers] A CMAKE_EMULATOR variable

[Matt McCormick]

Hi,

I have pushed to stage [1] support for a CMAKE_EMULATOR variable to
help when cross-compiling.  The goal is to improve cross compiling
with CMake by making it easier to build and run tests.  In principle,
the commands

  cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake
-DCMAKE_EMULATOR=/path/to/emulator ~/src/project
  cmake -D Experimental

are all that is needed generate a dashboard report, complete with test
results.  This should inch C/C++ closer to being the "write once, run
anywhere" languages :-).

The emulator is used to run try_run results, which avoids manual
population of TryRunResults.cmake.  This can be a painful,
time-consuming process otherwise.

It is also used to run tests on executables that are built for the
target system.  Without this approach, it is difficult to know which
tests should be executed on the target system.  Tests are often passed
absolute paths to input on the host system.  The use of an emulator is
a way to avoid complexities and transfer overhead related to
reproducing the host filesystem on the target filesystem to run the
tests.


With some fixes to ITK [2], this was used to build and test for four
cases of interest.

The emulator approach works best with MinGW and WINE to build and test
on Linux for Windows [3].

The qemu-arm emulator provided by QEMU User Mode can be used with the
Android NDK toolchain [4]. A gotcha is that Android tries to be fancy
and uses its own dynamic loader.  To get around this, I tested with
completely static executables.  Also, QEMU User Mode does not
currently support multi-threading well, so tests were run
single-threaded. An alternative approach may be to use an emulator
script that is a wrapper around adb.

The qemu-arm emulator was used again with the Raspberry Pi toolchain
[5].  A symbolic link was created in the expected location for
ld-linux-armhf.so.3, and dynamic loading works.  To run the tests,
LD_LIBRARY_PATH was populated with the path to libc and libstdcxx.

One of the most interesting combinations is the Emscripten toolchain
with NodeJS as the emulator [6]. There are some WIP workarounds to get
Emscripten to configure cleanly for scientific libraries [7], and code
had to be injected into the test driver to mount local filesystems for
node, but this works surprisingly well.


Testing and feedback are appreciated.

Thanks,
Matt


[1] http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/emulator

[2] https://github.com/thewtex/ITK/tree/cmake-emulator

[3] https://open.cdash.org/buildSummary.php?buildid=3694578

[4] https://open.cdash.org/buildSummary.php?buildid=3694810

[5] https://open.cdash.org/buildSummary.php?buildid=3694810

[6] https://open.cdash.org/buildSummary.php?buildid=3705525

[7] https://github.com/thewtex/emscripten/tree/test-big-endian