qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: [c++] Simplifying test environments and running tests on installations
Date Fri, 06 Nov 2009 20:53:24 GMT
On Fri, 2009-11-06 at 09:15 -0500, Alan Conway wrote:
> On 11/05/2009 12:23 PM, Andrew Stitcher wrote:
> > On Thu, 2009-11-05 at 10:07 -0500, Alan Conway wrote:
> >> ...
> >> There is another issue and I'm not sure how to resolve it.
> >>
> >> Some modules (e.g. xml, cluster etc) are optional and only built if so
> >> configured. The problem is when
> >>    - in a checkout, optional module foo  not built
> >>    - qpidd is installed in default place _with_ module foo
> >> If we rely on OS paths then --load-module foo will pick up foo from the install.
> >> What we want is tests that depend on foo be skipped if its not available.
> >>
> >> One solution I'm considering is to set an env var QPID_TEST_MODULE_DIRS
> >> containing the "blessed" dirs from which we want to load modules. Tests that
> >> an optional module would first check for it in QPID_TEST_MODULE_DIRS, and if
> >> present would run the test. The test still uses --load-module foo with  no path
> >> so the module dirs would also be prepended to LD_LIBRARY_PATH or the windows
> >> equivalent.
> >>
> >> Any thougts on whether that's a reasonable fix or anyone have a better solution?
> >>
> >
> > Don't we already have an option --module-dir ? Couldn't that be used?
> >
> > Answering my own question - not exactly, because --module-dir is an
> > instruction to load all the modules in that directory, not a restriction
> > of modules to that one place.
> >
> > Perhaps the module loading options aren't well factored:
> >
> > I think it should maybe work like this:
> >
> > If there is no --module-dir option then use the compiled in default for
> > the module directory.
> >
> > If there is a --module-dir then use that specified directory.
> >
> > However we *only* look in that directory for modules by default.
> > [I guess if there are multiple --module-dir options then we should look
> > in all the directories, but I'm not sure that we can currently do this.]
> >
> > In the absence of any --load-module options we go and load *all* the
> > modules in that directory. This is overridden with the --no-module-dir
> > option, which would now be misnamed and should be better called
> > --no-load-modules.
> >
> > However if there are any --load-module options then we only load the
> > modules specified. If the module is just an name it gets the standard
> > suffix for the platform (.so/.dll) and is only loaded from the module
> > directory. If the module is a full path (starting with '/' for unix for
> > instance) then it is loaded absolutely.
> >
> > We could add a convenience feature --no-load-module which would remove a
> > module that was in the default list, but this would be strictly
> > convenience.
> >
> > I think this proposal regularises the current slightly messy module
> > loading semantics - what do others think?
> >
> Making --module-dir have 2 different meanings based on the presence of other 
> options seems confusing to me. E.g. if I have 2 --module-dir options plus a 
> --load--module option then what do I do?

No I'm suggesting that --module-dir has only one function (not 2) -
specify the module directory (sort of) as present. The change I'm
suggesting is to make it only specify, not to act as a command to load
all modules in the directory.

In the case you suggest the semantics would be:

Add both module directories to the places to find modules, then if the
--load-module option isn't an absolute path only look in those places.

> I think the current semantics are quite clear:
>    --load-module foo: load module named foo, located by standard OS-specific 
> library loading mechanism if full path is not specified.
>    --module-dir foo: load all modules found in directory foo.

The semantics are clear, but wrong I think, as relying on the system
default LOAD_LIBRARY_PATH isn't good in almost any scenario - as we
never install there and don't intend to.

> What you're suggesting (I think) is that we provide a way to specify the search 
> path for explicitly loaded dirs through options.  We could do that with a 3rd 
> option, e.g.
>   --module-path foo: search for modules in directory foo
> but I don't see the point of duplicating an OS feature that is well understood 
> with a qpid-specific feature.

Because the OS feature isn't useful and is perhaps harmful for us. We
really only want to look for our modules in our own directories which
will never (should never) be on the search path.

I've used something close to this approach before and it works well.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message