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:[email protected]
