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 Thu, 05 Nov 2009 17:23:46 GMT
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?

Andrew



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


Mime
View raw message