On Fri, 2013-11-08 at 11:15 -0500, Justin Ross wrote: > On Fri, Nov 8, 2013 at 10:54 AM, Andrew Stitcher <astitc...@redhat.com> wrote: > >> > 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. > > > > I agree - I tend to regard (somewhat chauvinistically I admit) the c++ > > qpid-send and qpid-receive as the default versions! > > For what it's worth (and I wouldn't say it's worth much), I'd prefer > renaming the C++ ones as well. I think it does a better job of > telling the user what they're using, one of several variants of > qpid-send or -receive.
I think there is a difference of mindset then. I view qpid-send/qpid-receive as generally useful utilities, that perhaps should be installed by default when we install qpid-clients. For simple enough cases they allow you to send/receive messages from the command line with no further tooling. And for this purpose on of the variants needs to be the default installed - I'd suggest the native code versions might be best suited. So keeping them called just qpid-send/receive works best for this. I'd certainly not object to installing links to them as part of the tests called qpid-cpp-send/receive. I think of the current set of "test" executables they are the only ons that qualify to be generally useful. Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
