Hi Alan, > 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. > > > > 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. > > Yes, I was thinking there would be a separate env script per > platform. That > doesn't affect the test scripts since the env script would be > run by make, outside the test scripts.
Ok. > > 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. > > > > Interesting idea - do an install in a subdivide of tests as > part of make check. Or, do something like: make make install make check > I'm not sure if automake is up to the job, as the install > prefix is set as > part of configure. Maybe it can be over-ridden, I'll poke > around. Ok. Also note below... > Does cmake support that type of install as part of the test phase? Not an implicit install, no, but there's a install target in the generate makefile, similar to the automake world. And the install location is set during configure here as well, possibly overridden later. BTW, the plan of record (at least last I knew) was to migrate everything to CMake and drop autoconf. I've noticed that many changes made to Makefile.am don't necessarily make it over to CMakeLists.txt and am wondering where the commitment level is for CMake transition (in general with the primarily Linux folks, not Alan in particular). -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
