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 Mon, 09 Nov 2009 14:33:22 GMT
On 11/06/2009 03:53 PM, Andrew Stitcher wrote:
> 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.

I take your point about the semantics, but I still think its desirable to 
distinguish "this is a place to look for modules" from "take all the modules 
from this place and load them" more explicitly. E.g. suppose you do want to load 
all modules in dir X but also load  individually modules in dir Y.

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

I now agree with you, searching the OS path isn't useful. So how about:

--load-module-dir DIR: load all modules found in DIR. Defaults to /usr/lib or 
whatever
--no-module-dir: don't automatically load modules from any directory, load only 
those specified by --load-module
--load-module MODULE: load MODULE, search in directories specified by 
--search-module-dir
--search-module-dir DIR: include DIR in the list searched by --load-module

That has the benefit of being backward compatible, supporting the desired 
default behavior if nothing is specified (load from standard dir) as well as 
addressing your concern with not using the OS path.

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


Mime
View raw message