Re: [cmake-developers] A CMAKE_EMULATOR variable
On Mon, Apr 6, 2015 at 10:24 AM, Brad King brad.k...@kitware.com wrote:
On 04/05/2015 11:07 PM, Matt McCormick wrote:
In each place that you ExpandListArgument to get the emulator
command and arguments and write them out before an executable
name, you need to be sure to make the proper call to escape
each argument. In each case the code just below your hunk
does this for the test arguments.
Good catch. Fixed.
Thanks. In try_run:
+finalCommand += ;
+for (std::vectorstd::string::const_iterator ei =
+ emulatorWithArgs.begin()+1;
+ ei != emulatorWithArgs.end(); ++ei)
+ {
+ finalCommand += *ei;
+ finalCommand += ;
+ }
This still doesn't quote the arguments to the emulator.
It needs to be quoted enough to get through the command line
parsing that try_run does later. Or, things need to be
refactored to avoid extra quoting/parsing steps.
Missed that one. Quotes have been added.
The Tests/RunCMake/pseudo_emulator.cxx tool must be able to
compile with any of the compilers we test, not just those that
host the build of CMake. It will be more portable to use a
.c file with stdio.h and printf.
The pseudo_emulator still needs to be converted to C, please.
Done.
Thanks for the reviews. Merged to next.
Thanks,
Matt
--
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
Re: [cmake-developers] A CMAKE_EMULATOR variable
On 04/05/2015 11:07 PM, Matt McCormick wrote:
In each place that you ExpandListArgument to get the emulator
command and arguments and write them out before an executable
name, you need to be sure to make the proper call to escape
each argument. In each case the code just below your hunk
does this for the test arguments.
Good catch. Fixed.
Thanks. In try_run:
+finalCommand += ;
+for (std::vectorstd::string::const_iterator ei =
+ emulatorWithArgs.begin()+1;
+ ei != emulatorWithArgs.end(); ++ei)
+ {
+ finalCommand += *ei;
+ finalCommand += ;
+ }
This still doesn't quote the arguments to the emulator.
It needs to be quoted enough to get through the command line
parsing that try_run does later. Or, things need to be
refactored to avoid extra quoting/parsing steps.
The Tests/RunCMake/pseudo_emulator.cxx tool must be able to
compile with any of the compilers we test, not just those that
host the build of CMake. It will be more portable to use a
.c file with stdio.h and printf.
The pseudo_emulator still needs to be converted to C, please.
Thanks,
-Brad
--
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
Re: [cmake-developers] A CMAKE_EMULATOR variable
In each place that you ExpandListArgument to get the emulator command and arguments and write them out before an executable name, you need to be sure to make the proper call to escape each argument. In each case the code just below your hunk does this for the test arguments. Good catch. Fixed. The Tests/RunCMake/pseudo_emulator.cxx tool must be able to compile with any of the compilers we test, not just those that host the build of CMake. It will be more portable to use a .c file with stdio.h and printf. Also, please make it print out each argument in quotes so one could match expected output in the future. Done. If I recall correctly, there are not other tests that try to verify try_run output, so I did not open that can of worms. +RunCMake_TEST:STRING=AddTest Why is this needed in InitialCache.cmake? Seems like leftover cruft. Removed. Thanks for the review. The new branch has been force pushed to the stage as emulator-property. Thanks, Matt -- 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
Re: [cmake-developers] A CMAKE_EMULATOR variable
On 03/29/2015 09:32 PM, Matt McCormick wrote: That sounds cool. I have implemented it in the emulator-property branch [1]. The variable name that defines the default for the CROSSCOMPILING_EMULATOR property is CMAKE_CROSSCOMPILING_EMULATOR. Thanks. That looks pretty good, but needs some tweaking: In each place that you ExpandListArgument to get the emulator command and arguments and write them out before an executable name, you need to be sure to make the proper call to escape each argument. In each case the code just below your hunk does this for the test arguments. The Tests/RunCMake/pseudo_emulator.cxx tool must be able to compile with any of the compilers we test, not just those that host the build of CMake. It will be more portable to use a .c file with stdio.h and printf. Also, please make it print out each argument in quotes so one could match expected output in the future. +RunCMake_TEST:STRING=AddTest Why is this needed in InitialCache.cmake? Thanks, -Brad -- 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
Re: [cmake-developers] A CMAKE_EMULATOR variable
Hi Brad,
On Thu, Mar 5, 2015 at 9:51 AM, Brad King brad.k...@kitware.com wrote:
On 03/04/2015 08:15 PM, Matt McCormick wrote:
On Wed, Mar 4, 2015 at 12:00 PM, Brad King wrote:
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.
This set of patches does not globally and unconditionally add a
launcher in front of all tests. It uses build system knowledge to add
the emulator commands in front of target executables only.
Good, but it may take more work. I see the key logic here:
cmTarget* target = mf-FindTargetToUse(exe);
if(target target-GetType() == cmTarget::EXECUTABLE)
{
// Use the target file on disk.
exe = target-GetFullPath(config);
+
+// Prepend with the emulator when cross compiling if required.
This if() condition is not sufficient to know that the executable
is for the target architecture. The cmTarget could be IMPORTED, in
which case we don't know whether it references a host tool or one
built for the target architecture. Some kind of target property
may be needed to say use the emulator to run me more explicitly.
Once we have such a property, then it might as well refer to the
tool to be used, e.g.
add_executable(myexe ...)
set_property(TARGET myexe PROPERTY CROSSCOMPILING_EMULATOR ${emulator})
The point about the overloaded meaning of targets is a good one. I
think the best name is then CMAKE_CROSSCOMPILING_EMULATOR.
Sounds good. This variable could be used to initialize the above
property on target creation (see SetPropertyDefault calls). In
try_run we simply need to pass the value into the inner project
and its executable will pick it up too.
That sounds cool. I have implemented it in the emulator-property branch [1].
The variable name that defines the default for the
CROSSCOMPILING_EMULATOR property
is CMAKE_CROSSCOMPILING_EMULATOR.
Thanks,
Matt
[1]
http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/emulator-property
--
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
Re: [cmake-developers] A CMAKE_EMULATOR variable
On 03/04/2015 08:15 PM, Matt McCormick wrote:
On Wed, Mar 4, 2015 at 12:00 PM, Brad King wrote:
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.
This set of patches does not globally and unconditionally add a
launcher in front of all tests. It uses build system knowledge to add
the emulator commands in front of target executables only.
Good, but it may take more work. I see the key logic here:
cmTarget* target = mf-FindTargetToUse(exe);
if(target target-GetType() == cmTarget::EXECUTABLE)
{
// Use the target file on disk.
exe = target-GetFullPath(config);
+
+// Prepend with the emulator when cross compiling if required.
This if() condition is not sufficient to know that the executable
is for the target architecture. The cmTarget could be IMPORTED, in
which case we don't know whether it references a host tool or one
built for the target architecture. Some kind of target property
may be needed to say use the emulator to run me more explicitly.
Once we have such a property, then it might as well refer to the
tool to be used, e.g.
add_executable(myexe ...)
set_property(TARGET myexe PROPERTY CROSSCOMPILING_EMULATOR ${emulator})
The point about the overloaded meaning of targets is a good one. I
think the best name is then CMAKE_CROSSCOMPILING_EMULATOR.
Sounds good. This variable could be used to initialize the above
property on target creation (see SetPropertyDefault calls). In
try_run we simply need to pass the value into the inner project
and its executable will pick it up too.
-Brad
--
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
Re: [cmake-developers] A CMAKE_EMULATOR variable
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 dlrd...@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.mccorm...@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:
Re: [cmake-developers] A CMAKE_EMULATOR variable
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
--
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
Re: [cmake-developers] A CMAKE_EMULATOR variable
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.mccorm...@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 dlrd...@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.mccorm...@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
Re: [cmake-developers] A CMAKE_EMULATOR variable
On Wed, Mar 4, 2015 at 12:00 PM, Brad King brad.k...@kitware.com wrote: 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. This set of patches does not globally and unconditionally add a launcher in front of all tests. It uses build system knowledge to add the emulator commands in front of target executables only. Test with host executables run with the host command. This is why it is advantageous to use the emulator in this way. 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 are difficult and take tweaking, but wrappers are a diversion here -- this is intended to be used with emulators or programs that act very close to emulators. It has been shown to work with ITK, a very large and complex project, and with a number of diverse cross-compiling toolchains and targets. No per-test tweaks were made in ITK's over 2500 tests. The point about the overloaded meaning of targets is a good one. I think the best name is then CMAKE_CROSSCOMPILING_EMULATOR. Thanks, Matt -- 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
Re: [cmake-developers] A CMAKE_EMULATOR variable
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.mccorm...@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
[cmake-developers] A CMAKE_EMULATOR variable
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
