[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