qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Draft Interop Testing Spec - Please Read
Date Fri, 02 Mar 2007 21:10:01 GMT
On Tue, 2007-02-27 at 20:43 +0000, Marnie McCormack wrote:
> Not too sure how to completely get round some system variables being set for
> the tests to run. For example, if you don't set JAVA_HOME or similar, how
> can you run the java command ? 
JAVA_HOME is Suns fault not ours ;) but you can run Java without
JAVA_HOME based on PATH - e.g. the standard gcj install works like that.
Our test suite should work either way.

> Can Alan or someone shed
> some light on how the scripts would work without some info about QPID_HOME
> type stuff ?

Scripts (programs in general) can figure out where they themselves are
installed and find their config files etc. by looking relative to that
without using env vars. E.g. add this as qpid/interop/qpid_java_env:

#!/bin/sh
export SCRIPT_DIR=`dirname $0`
ROOT=`dirname $SCRIPT_DIR`
export QPID_HOME=$ROOT/java/bin
export PATH=QPID_HOME/bin
# etc...

Now an imaginary test script first sources the environment as follows:

#!/bin/sh
# qpid_test
source `dirname $0`/qpid_java_env
echo QPID_HOME=$QPID_HOME

Finally I put /home/aconway/svn/qpid/interop in my path, now I can call
qpid_test from anywhere and it always prints:

[aconway@scooter /]$ qpid_test
QPID_HOME=/home/aconway/svn/qpid/java/bin

So now the user has only one thing to set - PATH - instead of 2 or 3,
which is important if you work in multiple checkouts and need to switch
easily from one to another. You can also run tests from a different
checkout *without* setting paths by simply saying:
 /home/aconway/svn/qpid2/interop/run_test
and automatically the environment is set for /home/aconway/svn/qpid2

(NB: the example above fails if you are in a subdirectory of qpid and do
something like ../../interop/run_test, a slightly more complicated
script can handle that case too.)

> Once the spec is agreed (probably we need to draw a line in the sand
> somewhere here ?) I think we need to:
> 
> - document on the wiki
> - prioritise some elements
> - split into compact JIRAs, by technology, so that individuals can pick up
> the tasks and contribute (we don't have too many all-code-all-clients people
> on the project !)

I'm happy with the proposal so far, once this gets underway I'll try to
put my code where my mouth is for any further suggestions ;) 

Cheers,
Alan.


Mime
View raw message