Mailing-List: contact dev-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of aconway@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <4AF42F95.6030500@redhat.com>
Date: Fri, 06 Nov 2009 09:15:49 -0500
From: Alan Conway <aconway@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4
MIME-Version: 1.0
To: dev@qpid.apache.org
Subject: Re: [c++] Simplifying test environments and running tests on
 installations
References: <662D6446FADF4C67BD23CCB6DC8BA9DF@hope>
	 <4AEB16A3.7040700@redhat.com>  <4AF2EA3C.6070407@redhat.com>
 <1257441826.3346.73.camel@localhost.localdomain>
In-Reply-To: <1257441826.3346.73.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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