qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: [c++] Simplifying test environments and running tests on installations
Date Fri, 06 Nov 2009 14:15:49 GMT
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?

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.

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.

All that said, I'm becoming ambivalent about this approach to the tests. I'm 
concerned about the potential for test on a checkout to accidentally pick up 
modules and executables from a default install on the same host. I still don't 
have a solution for tests that's really satisfying.

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

View raw message