Thanks AlanWhen I emailed yesterday about Unicode things it was that email I
was looking for to check what the tests were that you wanted doing. All the
best Phil
From: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
To: phil rosenberg <philip_rosenb...@yahoo.com>
Cc: "plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>
Sent: Thursday, 2 October 2014, 21:04
Subject: Re: [Plplot-devel] Testing on Windows
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
