Re: [Plplot-devel] NAG whitespace issues

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

On 2016-05-25 06:25-0000 Arjen Markus wrote:

> I already installed it [NAG Fortran] in a non-default location. The
"EFBuilder 6.1" part of the path comes from the installation itself. I
set the installation directory to "d:\NAG".

> I just examined the PATH variable: it contains the directory
"D:\NAG\EFBuilder 6.1\bin". I suspect that CMake finds pkg-config.exe
via this path. So we are pretty much stuck with this behaviour.

Too bad NAG put spaces in their internal pathnames.  Ugh.  I suggest
you report that issue to them since it gratuitously creates problems for
those building free software packages such as PLplot.

Here is another possible workaround for this situation. I presume you
are working with either Cygwin or MinGW-w64/MSYS2 which have their own
non-NAG versions of pkg-config, freetype, etc., available.  If so, put
"D:\NAG\EFBuilder 6.1\bin" at the end of the PATH and not the start.
The result should be that the non-NAG version of pkg-config is found
and that, in turn, should find the non-NAG version of freetype.  This
idea is based on the assumption that the NAG software installation
does not fiddle with the PKG_CONFIG_PATH environment variable, but
there are ways to get around that if necessary.  The other assumption
I am using here is NAG supplies pkg-config, freetype (and presumably
its own versions of other useful build tools and libraries) for
customer convenience and not as a necessity for the NAG compiler to
work properly.  (If the NAG compiler relied directly on certain free
software tools and libraries, i.e., this is more than just providing a
convenience for customers, then there might be a version mismatch
issue if you substituted Cygwin or MinGW-w64/MSYS2 versions of tools
and free libraries for NAG ones.)

With regard to the eventual build-system fix for spaces in pathnames,
I have been doing a lot of further investigation, and one of the
primary issues is that our build system uses the COMPILE_FLAGS
property virtually everywhere (since that was the only way to work
with compiler flags in CMake a decade ago.) That property is a
space-separated string containing the various compiler flags, and that
makes it difficult/impossible to distinguish spaces in the various
parts of that string from the spaces that are supposed to separate
those parts. It turns out that CMake-3 deprecates COMPILE_FLAGS
(presumably for that space-separated reason) and instead provides the
COMPILE_OPTIONS choice which stores its results in a normal CMake
list.  It is a big undertaking for me to change our build system so
that it uses COMPILE_OPTIONS rather than COMPILE_FLAGS and processes
those results with normal CMake list processing rather than special
code to deal with the space separation. However, I believe that
massive cleanup to our build system will be worth it since I am pretty
sure many of our problems with spaces in path names will disappear as
a result.

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
__________________________