On 11/08/2013 03:37 PM, Andrew Stitcher wrote:
On Fri, 2013-11-08 at 11:43 +0000, Gordon Sim wrote:
Since both the existing tests already import qpid.messaging this isn't
actually imposing any significant extra dependency. There are also
python equivalents of qpid-send and qpid-receive.
Providing we keep the ability recently added to qpid-cpp-benchmark to
specify the path to qpid-send and qpid-receive, that test can then be
used to run either c++ or java based equivalents.
One disagreement I may have here is that I think we should retain
different names for the different implementations of qpid-send and
qpid-receive. So I think we need to add an option to qpid-benchmark to
not only set the path it uses to find them, but also the names of the
executables it uses. An approach the works for the Java testing is to
use "profiles" that set a bunch of related parameters and that can be
switched as a whole.
The reason I want to do this is that I want to move to a testing regime
where we can run a specific build and use its install result (with
probably a special testing tools install location) to run the subsequent
test run. If we are to do this with multiple of the the qpid subtrees
together, say c++ and java then it will be confusing if the *-send and
*-receive executables have the same name.
I wouldn't object to such an option.
I'd be much less keen on renaming the existing c++ tests though.
Since the java test scripts already use a different name, then renaming
the python equivalents (which are rarely used at present) would then be
all that was required.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
