On 2014-10-02 13:44-0000 phil rosenberg wrote: > Hi I've started looking a bit into the testing on Windows. This was mostly initiated because I accidentally built the test_interactive project which CMake creates for VC++ builds and it popped up a wxWidgets window - so with Cygwin installed it does seem there is hope for getting the tests to work.
That indeed sounds promising. > I then tried the RUN_TESTS project and a couple of other test projects without much luck. A handful of problems immediately stuck out > 1) My build directory has spaces - I know a recipe for making life difficult - however I do this because I use the name of the generator, the config type and a flag for static or dynamic as part of my build directory name so I get different directories for 64/32 bit static/dynamic and release/debug combos. As the generators have spaces, so do my paths. Running ctest with -VV gives the output > 5: Test command: C:\cygwin64\bin\bash.exe "-c" > "EXAMPLES_DIR=D:/usr/local/src/pl > plot-plplot/build/Visual Studio 11 64s/examples > SRC_EXAMPLES_DIR=D:/usr/local/sr > c/plplot-plplot/examples > OUTPUT_DIR=D:/usr/local/src/plplot-plplot/build/Visual > Studio 11 64s/ctest_examples_output_dir ./plplot-test.sh --verbose > --front-end=c > --device=xfig" > 5: Test timeout computed to be: 1500 > 5: /usr/bin/bash: Studio: command not found > Basically the spaces in the path are messing up the command passed to bash. Alan, do you know if this is something we can control or is it a cmake/ctest bug? Hi Phil: I am virtually positive this is something we can control by inserting the correct escaped double quotes in the plplot_test/CMakeLists.txt file and/or the other bash script files in that directory. However, I don't have the time at the moment to help you debug this yourself. But when you do come up with a solution, I can test it on Linux by using a build tree name with a blank in it. > Running the test command myself with the spaces escaped correctly leads to another couple of bugs being discovered > 2) The shell scripts used in the tests are given Windows line endings by Git when downloaded and bash complains a lot about that. Is there any way we can flag to Git to keep the Linux line endings for the shell scripts? I am not sure whether there is a git config item for this or not. However, I am surprised your version of bash complains about that. What is the source of that bash version? > Running dos2linux on the files is the immediate workaround for this, but then > I hit one more snag > 3) When I run the script with corrected line endings I get the following error./test_c.sh: line 44: D:/usr/local/src/plplot-plplot/build/Visual Studio 11 64s/ examples/c/x00c: No such file or directory >Checking I find the error is correct. Instead my executables are in examples/c/Release or examples/c/Debug i.e. they are in a directory which corresponds to the configuration type. If I copy my executables up one level then I can run the test and it works fine, giving me a host of postscript files in this case in the ctest_examples_output_dir. Sounds promising. Instead of moving stuff around wouldn't it be easier to just set the PATH appropriately? To deal with this issue, please follow up on a previous request of mine that you test the use of setting RUNTIME_OUTPUT_DIRECTORY (preferably alone, but if that doesn't bring in the dynamic devices) set both RUNTIME_OUTPUT_DIRECTORY LIBRARY_OUTPUT_DIRECTORY to replace our current setting of just LIBRARY_OUTPUT_PATH in our top-level CMakeLists.txt file. I am concerned setting RUNTIME_OUTPUT_DIRECTORY is going to move all the examples from their correct locations in the examples tree to the dll subdirectory, so you may have to experiment by unsetting RUNTIME_OUTPUT_DIRECTORY in the examples directory. The above is for the shared libraries/dynamic devices case. But for the static case, I think setting RUNTIME_OUTPUT_DIRECTORY will do what you want (subject to the examples caveat). You might also want to experiment with ARCHIVE_OUTPUT_DIRECTORY for the static library case. The result of the new settings should be all executables, dynamic device dll's, and shared libraries and static libraries should be collected in convenient locations in the build tree, and once those locations are right, then setting your PATH appropriately should completely settle this issue. > So It seems there are three things that need addressing here1) Spaces in paths (again)2) Windows/Linux line endings in scripts3) Different build locations for the examples using Windows/VC++ compared to on Linux/gcc systems > Initially any suggestions for which of these we can deal with and which need to be passed on to CMake would be good. Alan I'm looking towards you obviously here for advice. Once we know what we can deal with I can look at options. I don't think any of these will need to be passed on to CMake. (1) is a lot of work, but that is on us (actually as I stated above because of my time constraints probably completely on you except for the testing). (2) has a whole host of potential solutions. There may be a git configuration item, the solution might be to use a different version of bash such as the MSYS version. But if nothing else works, then we can insert logic in our build system to automatically run the appropriate command on Windows to remove the extra "\r" characters if they are there. (3) requires some more experimentation on your part with one of/all of RUNTIME_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and/or ARCHIVE_OUTPUT_DIRECTORY variables, but once those have been deployed correctly, the solution becomes a simple one of merely setting your PATH. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
