qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Huston" <shus...@riverace.com>
Subject RE: [c++] Simplifying test environments and running tests on installations
Date Fri, 06 Nov 2009 21:18:25 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 use
> > >> 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.

A startup script can always set LD_LIBRARY_PATH.

> > 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.

It could be argued that the init script can change the LD_LIBRARY_PATH
for starting qpidd.

The --module-dir can be a relative path, can be set in the configure
file based on installation information, etc.

Also, trying to evade the OS policy is 1) confusing for people who
understand the policy, like sysadmins, and 2) a potential security
hole. I've done this before and would like to never go back.

-Steve


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


Mime
View raw message