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. Yes, I agree. > Are there any other problems I've missed? Possibly with different locations of the resultant libs, etc. on different platforms, but this should be workable. It may be an idea to make install (and the equiv on Windows) before running the tests. Then things could be in a predictable place and more closely mimic what will be in a user site. > Will the same > approach work on windows with .bat files instead of sh scripts? Windows PowerShell scripts, yes. -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
