Jonathan Robie wrote:
On 07/21/2010 04:21 PM, Rafael Schloming wrote:
I think you should forget about make and simply provide a convenient
command line interface to running the tests (either via qpid-python-test
or a custom script if appropriate).
This can then be used to test interop outside of the source tree and can
be trivially integrated by C++, Java, and/or python developers into
their respective builds.
This, I think, is already done in the current code.
Run it like this:
$ ./client-api-example-tests.py -v
By default, it assumes it is being run from a Qpid source tree, and sets
up paths to the test programs in their normal locations, then runs them.
You don't have to configure anything if it's being run from a source
tree with a broker on localhost:5672. If your broker is running at a
different address, set QPID_BROKER to the address of the broker.
If you're running it from outside a source tree, but have the source
tree on your system, set QPID_ROOT to the source tree root.
If you're running from an installed version, you have to tell the script
where you installed various pieces using the following environment
variables:
QPID_CPP_EXAMPLES (default: qpid_root + "/cpp/examples/messaging/")
QPID_PYTHON_EXAMPLES (default: qpid_root + "/python/examples/api/")
PYTHONPATH (default: qpid_root+"/python:" + qpid_root+"/extras/qmf/src/py")
QPID_PYTHON_TOOLS (default: qpid_root + "/tools/src/py/")
QPID_HOME (default: qpid_root + "/java/build/lib/")
QPID_JAVA_EXAMPLES (default: qpid_root + "/java/client/example/")
I think that should be fairly easy to set up and call from various
environments.
I was aware of this already, but I was only able to figure it out by
reading the source code.
By convenient command line interface I meant something more in line with
the usual unix standards, e.g. I should be able to figure out how to use
the program from the -h/--help option, and it shouldn't dump logging
into a random hard coded filename in the current directory and
configuration should be controllable via options with environment
variables for defaults only.
An alternative (and possibly a better one) would be to simply integrate
with the qpid-python-test runner which does much of the above for you.
Either way I think that defaulting the script itself to pick stuff up
from the source code layout is a problem. This code is currently sitting
in a place where it will get installed and when this happens you'll end
up with an installed script that by default will break horribly because
all of its default expectations are wrong for the installed environment.
It would make more sense to depend on standard environment variables
(i.e. PATH) already being set correctly. This would allow the script to
work correctly by default in an installed environment, and any
integrating Makefile/build.xml/setup.py can easily set up the PATH as
needed for the source tree.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
