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 Thu, 05 Nov 2009 15:07:40 GMT
On 10/30/2009 12:38 PM, Alan Conway wrote:
> On 10/30/2009 11:03 AM, Steve Huston wrote:
>> Hi Alan,
>>
>>> For tests that run executables and scripts (tests that are
>>> bash scripts, python
>>> scripts) we currently are setting a lot of ad-hoc environment
>>> variables so those tests can locate exes and libraries.
>>
>> Yes, I've been struggling with translating that for Cmake on both
>> Linux and Windows.
>>
>>> I propose to rationalize this as follows:
>>>
>>> 1. Rewrite the tests with NO paths on executables or
>>> libraries in --load-module options.
>>>
>>> 2. Write a testenv script to set up PATH and LD_LIBRARY_PATH
>>> with paths where
>>> exes, scripts and libraries are found in a build at the
>>> front. Source these scripts before running the tests.
>>
>> Ok.
>>
>>> The benefits are:
>>> - simpler scripts, fewer env vars to think about
>>> - can write additional env scripts to run tests in other
>>> settings e.g..
>>> - run tests against installed qpidd
>>> - run tests against store module and qpid built in 2
>>> separate build trees.
>>
>> Cool.
>>
>>> The only downside I can think of is that if an exe fails to
>>> build and qpid is
>>> installed you might run with installed exe or lib by mistake.
>>> However this
>>> presupposes you didn't notice that your build failed so the
>>> risk seems minor compared to the benefits.

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?

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


Mime
View raw message