[Plplot-devel] Space in full pathname issues

[Alan W. I. <ir...@be...>]

On 2017-05-03 00:42-0700 Alan W. Irwin wrote:

> [....]It turns out there
> are 4 kinds of these type of issues where the spaces(s) occur in the
> full pathname of (1) the source tree, (2), the build tree, (3), the
> install tree, and (4) the system libraries and executables that PLplot
> uses.
>

> More later once I make some significant progress on (1), (2), and
(3)

Hi Arjen:

I am putting this thread on the plplot-devel mailing list because these changes
should impact all our advanced Windows users (and also POSIX users who
are in the habit of putting spaces in the full path names that they use).

See commits d9fffdda and f432893 for what I have done on this topic so
far.  For the first of those my fix passed a comprehensive test for
case (1) (except for Ada, D, and OCaml language support issues for
this case that I will attempt to fix later).

When I looked at case (2), more issues showed up. The first of those
was for the test_tcl_psc target which I fixed in the last commit
above.  Since the file I changed is the same one that you have worked
on recently I expected I might encounter a conflict, but it turned out
you had delayed committing your work so that was not a problem for me.
On the other hand, you might have a conflict to resolve (by using the
well-known git method to choose my code change or yours or a
combination of the two if our changes impacted the same lines of the
file).  But whatever further changes (if any) you make to my changes,
please test the result by building the test_tcl_psc target and running
ctest on MinGW-w64/MSYS2, Cygwin, and MSVC.

I expect I will have additional fixes (likely all non-Tcl) soon for
case (2) and case (3) so I appreciate your expressed willingness to
keep plugging away on any case (4) issues you encounter (which are
fairly common on Windows).  Eventually, I plan to do a Linux epa_build
with install prefix containing spaces to test for case (4) issues as well.

@Others here:

All our "test_*" targets such as test_tcl_psc are custom targets that
typically execute a bash script to do the heavy lifting for a given
test.  (These same test bash scripts are executed by the ctest command
that we have configured.) Of course, the normal Unix commands such as
cd, cp, mv, rm, etc. are used within those test bash scripts.

I was able to add MSVC to the above list of platforms I asked Arjen to
test in this semi-automatic way because he has gotten our test targets
to execute correctly on MSVC, and he plans to follow up with ctest
results as well as soon as one overall ctest issue he encountered is
fixed. He made all this work by putting the location of the
MinGW-w64/MSYS2 Unix tools last on the PATH.  The bash.exe application
can be run from a CMD environment so what happens is CMake-generated
nmake build rules which are implemented strictly using the CMD
environment invoke bash.exe to execute the bash scripts that are used
for testing all the ordinary build targets (e.g., bindings and
examples) that have been created by nmake using the ordinary CMD
environment.

So although this testing concept is somewhat complex, it does
fundamentally work, and the result is MSVC is much more convenient to
test in this semi-automatic way since our entire bash-related test
infrastructure is now available for that purpose on that platform
without impacting the ordinary MSVC build targets. Of course, we
expect tests done in this new way are likely to find a number of
build-system issues on MSVC, but cleaning those up should make PLplot
more much reliable on the vanilla MSVC platform (i.e., without the
Unix tools on the PATH that were put there just for these testing
purposes).

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
__________________________