[cmake-developers] A CMAKE_EMULATOR variable

Florent Castelli florent.castelli at gmail.com
Wed Mar 4 11:40:59 EST 2015


Sometimes, it’s not just about an emulator but a wrapper script that can run the target binary on a remote host or with the right environment (or use valgrind, helgrind, whatevergrind...).

I’d be nice to have the option in ctest to use some script to run a test program and an option to set it from CMake globally or when running ctest directly.

/Orphis

> On 04 Mar 2015, at 17:06, Matt McCormick <matt.mccormick at kitware.com> wrote:
> 
> Yes:
> 
>> it emulates the target system when cross-compiling, and
>> executables built for the target system can be run when passed to the
>> emulator.
> 
> is exactly correct.
> 
> Perhaps the name CMAKE_TARGET_SYSTEM_EMULATOR is necessary to resolve
> the ambiguity.  Or...
> 
> Thanks,
> Matt
> 
> On Wed, Mar 4, 2015 at 6:49 AM, David Cole <DLRdave at aol.com> wrote:
>> What does CMAKE_EMULATOR emulate?
>> 
>> From its name, it sounds like it emulates CMake. But from your description,
>> I'm thinking that doesn't make sense... Because you actually run CMake and
>> pass it CMAKE_EMULATOR. So it must be emulating something else while running
>> CMake?
>> 
>> I'm guessing it emulates the target system when cross-compiling, and
>> executables built for the target system can be run when passed to the
>> emulator? Is that right?
>> 
>> 
>> D
>> 
>> 
>> 
>> On Wednesday, March 4, 2015, Matt McCormick <matt.mccormick at kitware.com>
>> wrote:
>>> 
>>> 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
>>> --
>>> 
>>> 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:
>>> http://public.kitware.com/mailman/listinfo/cmake-developers
> -- 
> 
> 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:
> http://public.kitware.com/mailman/listinfo/cmake-developers



More information about the cmake-developers mailing list