Add remote-test capability, add unit test framework #39

Merged
merged 9 commits into from Feb 16, 2013

Conversation

Projects
None yet
2 participants
@joshuawarner32
Contributor

joshuawarner32 commented Feb 15, 2013

From the commit:

To execute tests on a remote host (for instance, because you're cross-compiling),
simply do:

make remote-test=true remote-test-host=<host_to_test_on> test

You can set several variables to control the functionality of remote-test.
See them below, along with their default values:

remote-test-host = localhost # host to ssh to
remote-test-port = 22
remote-test-user = ${USER} # user to execute tests as
remote-test-dir = /tmp/avian-test-${USER} # dir to rsync build output to

I also added a simple c++ unit-test framework, for testing individual pieces of the VM internals, and a couple simple tests.

"make test" works on [linux, windows, darwin]x[x86, x86_64], and "make test remote-test=true" works from [linux, darwin]x[x86_64] to [linux]x[x86_64, powerpc, arm] (where []x[] denotes a cross-product).

Joshua Warner and others added some commits Feb 15, 2013

add remote-test capability
To execute tests on a remote host (for instance, because you're cross-compiling),
simply do:

make remote-test=true remote-test-host=<host_to_test_on> test

You can set several variables to control the functionality of remote-test.
See them below, along with their default values:

remote-test-host = localhost # host to ssh to
remote-test-port = 22
remote-test-user = ${USER} # user to execute tests as
remote-test-dir = /tmp/avian-test-${USER} # dir to rsync build output to
@dicej

This comment has been minimized.

Show comment Hide comment
@dicej

dicej Feb 15, 2013

Member

On Fri, 15 Feb 2013, Joshua Warner wrote:

make remote-test=true remote-test-host=<host_to_test_on> test

Could we simplify that to eliminate the remote-test variable? If
remote-test-host is set (i.e. nonempty), use it, otherwise run the test
locally.

Member

dicej commented Feb 15, 2013

On Fri, 15 Feb 2013, Joshua Warner wrote:

make remote-test=true remote-test-host=<host_to_test_on> test

Could we simplify that to eliminate the remote-test variable? If
remote-test-host is set (i.e. nonempty), use it, otherwise run the test
locally.

@joshuawarner32

This comment has been minimized.

Show comment Hide comment
@joshuawarner32

joshuawarner32 Feb 16, 2013

Contributor

If remote-test-host is set (i.e. nonempty), use it, otherwise run the test
locally.

I don't think that's a great idea, because then I loose the ability to just specify the port. I have a couple of qemu vms that are listening on a couple different ports on localhost, and remote-test-host defaults to localhost, so my command is actually:

make arch=arm remote-test=true remote-test-port=5555 test

What about making remote-test be a separate target, e.g.:

make arch=arm remote-test-port=5555 remote-test

I think the ultimate solution is to switch from a one-makefile-to-rule-them-all system to something closer to configure or CMake, where you specify a set of configuration variables once, and just call "make" or "make test", etc. from within the build directory (e.g. build/linux-x86_64) from then on.

Contributor

joshuawarner32 commented Feb 16, 2013

If remote-test-host is set (i.e. nonempty), use it, otherwise run the test
locally.

I don't think that's a great idea, because then I loose the ability to just specify the port. I have a couple of qemu vms that are listening on a couple different ports on localhost, and remote-test-host defaults to localhost, so my command is actually:

make arch=arm remote-test=true remote-test-port=5555 test

What about making remote-test be a separate target, e.g.:

make arch=arm remote-test-port=5555 remote-test

I think the ultimate solution is to switch from a one-makefile-to-rule-them-all system to something closer to configure or CMake, where you specify a set of configuration variables once, and just call "make" or "make test", etc. from within the build directory (e.g. build/linux-x86_64) from then on.

@dicej

This comment has been minimized.

Show comment Hide comment
@dicej

dicej Feb 16, 2013

Member

On Fri, 15 Feb 2013, Joshua Warner wrote:

I don't think that's a great idea, because then I loose the ability to just
specify the port. I have a couple of qemu vms that are listening on a couple
different ports on localhost, and remote-test-host defaults to localhost, so
my command is actually:

make arch=arm remote-test=true remote-test-port=5555 test

Okay, then if any of the remote-test-* variables are nonempty, run it
remotely.

What about making remote-test be a separate target, e.g.:

make arch=arm remote-test-port=5555 remote-test

That would make sense if both the remote-test and test targets were useful
for a given config, but I'm guessing they normally wouldn't be.

I think the ultimate solution is to switch from a
one-makefile-to-rule-them-all system to something closer to configure or
CMake, where you specify a set of configuration variables once, and just
call "make" or "make test", etc. from within the build directory (e.g.
build/linux-x86_64) from then on.

Yeah, I like that, as long as it doesn't git as wildly complicated and
hard to debug as autotools-based builds are, and we never need to check
machine-generated files into Git.

Member

dicej commented Feb 16, 2013

On Fri, 15 Feb 2013, Joshua Warner wrote:

I don't think that's a great idea, because then I loose the ability to just
specify the port. I have a couple of qemu vms that are listening on a couple
different ports on localhost, and remote-test-host defaults to localhost, so
my command is actually:

make arch=arm remote-test=true remote-test-port=5555 test

Okay, then if any of the remote-test-* variables are nonempty, run it
remotely.

What about making remote-test be a separate target, e.g.:

make arch=arm remote-test-port=5555 remote-test

That would make sense if both the remote-test and test targets were useful
for a given config, but I'm guessing they normally wouldn't be.

I think the ultimate solution is to switch from a
one-makefile-to-rule-them-all system to something closer to configure or
CMake, where you specify a set of configuration variables once, and just
call "make" or "make test", etc. from within the build directory (e.g.
build/linux-x86_64) from then on.

Yeah, I like that, as long as it doesn't git as wildly complicated and
hard to debug as autotools-based builds are, and we never need to check
machine-generated files into Git.

joshuawarner32 added some commits Feb 16, 2013

set remote-test variable based on the presence of remote-test-host or…
… remote-test-port

The new way to run a remote test is:

make arch=<arch> remote-test-host=<host_to_test_on> test

@dicej dicej merged commit 5a5b924 into ReadyTalk:master Feb 16, 2013

1 check passed

default The Travis build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment