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] Extracting target metadata, IDE integration
On 03/02/2015 09:10 PM, Aleix Pol wrote: I created a new version of the patch: http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch Thanks. Samples: LLVM: https://paste.kde.org/pelr1ditp A small random KDE project: https://paste.kde.org/pgkbecv5p The location values need to be inside the configs elements because they can vary with the configuration in multi-config generators. Also the name location may not be specific enough. Some targets may have multiple output files (e.g. .dll, .lib). See the breakdown of $TARGET*FILE:... generator expressions: http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html#informational-expressions Some set of values like that will be more useful. If the the directory value is GetCurrentOutputDirectory, the build tree location of the project file, then that does not need to be per-configuration. In that case perhaps the name should be something like build_directory or project_directory. 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
[cmake-developers] [CMake 0015429]: Emacs: Please, inherit `cmake-mode' from `prog-mode'
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15429 == Reported By:Haroogan Assigned To: == Project:CMake Issue ID: 15429 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-03-04 15:23 EST Last Modified: 2015-03-04 15:23 EST == Summary:Emacs: Please, inherit `cmake-mode' from `prog-mode' Description: The title speaks for itself. Is there any particular reason that you decided not to make any inheritance for `cmake-mode'? Some people (including me) have things like (add-hook 'text-mode-hook 'fci-mode) (add-hook 'prog-mode-hook 'fci-mode) which make life easier, and that's exactly one of those features what proper mode inheritance was intended for. Please, consider using proper way of Emacs major mode definition, i.e. (define-derived-mode cmake-mode prog-mode CMAKE ... Thank you. == Issue History Date ModifiedUsername FieldChange == 2015-03-04 15:23 Haroogan New Issue == -- 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 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] [PATCH] CPack: change cpack_set_if_not_set into a function
If you work on that, please include tests (perhaps in the form of a new Tests/RunCMake/CPack directory), documentation updates, and a release note in a file such as 'Help/release/dev/cpack-maybe-set.rst'. For that you could rename Tests/RunCMake/CPackRPM to CPack and add your tests there - CMakeLists.txt and RunCMakeTest.cmake files should be what you need. Regards, Domen -- 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
