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
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
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.
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
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
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.
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
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
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
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
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
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
12 matches
Mail list logo