plplot-devel

Re: [Plplot-devel] PLplot Debian package

[Ole S. <deb...@li...>]

Hi Alan,

On 18.07.2017 20:45, Alan W. Irwin wrote:
> To Ole and Orion:
> 
> Here is what I suggest you do to decide whether you want to package
> the Octave bindings of PLplot until this UTF-8 error is fixed.  The
> octave examples that are run in our tests are controlled by
> plplot_test/test_octave.sh.in. That file has the "p" list and
> standard list of examples.
> There is nothing but ascii strings in the "p" examples
> so leave that list as is.  Of the standard examples, 18, 24, 26,
> and 33 are the ones that use UTF-8 strings (I derived that list by running
> 
> grep utf-8 examples/python/x??.py
> 
> .)
> 
> So to create a pure ascii test of Octave you should exclude
> those examples from the standard examples list.
> 
> Then build the test_diff_psc target, and make your packaging decision
> based on the results of that pure-ascii test of octave.
> 
> By the way, please run that test verbosely, e.g.,
> 
> make VERBOSE=1 test_diff_psc >& test_diff_psc.out
> 
> and if that output file still shows some errors for the pure ascii
> Octave test case, please send it to me.

All is fine for me after disabling [1] the mentioned tests. Since UTF-8
is one one case, I will keep the octave bindings in the 5.13.0 packaging.

One more small issue, which I reported some time ago to the Debian
package [2]: The pkgconfig file specifies the need to link to libshp:

$ pkg-config --libs plplotd
-lplplotd -lltdl -lm -lshp -lcsirocsa -lcsironn -lqhull -lqsastime

but in fact, -lshp is not needed. It would be nice if this linker flag
could be removed here.
(and, just to be sure: at that time, the library was called
"libplotlibd", while now it is "libplotlib" without the "d", right?)

Best regards

Ole

[1]
https://anonscm.debian.org/cgit/debian-science/packages/plplot.git/tree/debian/patches/Disable-octave-UTF-8-tests.patch
[2] https://bugs.debian.org/787818

Re: [Plplot-devel] PLplot Debian package

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

Hi Ole:

On 2017-07-19 15:15+0200 Ole Streicher wrote:

> All is fine for me after disabling [1] the mentioned tests. Since UTF-8
> is one one case, I will keep the octave bindings in the 5.13.0 packaging.

I am glad that you were able to prove that non-ascii UTF-8 in the user
strings is the only Octave-4.2 issue left.

> One more small issue, which I reported some time ago to the Debian
> package [2]: The pkgconfig file specifies the need to link to libshp:
>
> $ pkg-config --libs plplotd
> -lplplotd -lltdl -lm -lshp -lcsirocsa -lcsironn -lqhull -lqsastime
>
> but in fact, -lshp is not needed. It would be nice if this linker flag
> could be removed here.
> (and, just to be sure: at that time, the library was called
> "libplotlibd", while now it is "libplotlib" without the "d", right?)

Yes on the change in library name without the suffix d.

However, the above pkg-config results are dated and come from an
era when we didn't properly distinguish the shared and static
cases.  But the above results which included -lshp were correct
for the static case although incomplete in other ways.

Here are the pkg-config results from plplot git master branch (for a
non-standard install location):

software@raven> pkg-config --libs plplot
-L/home/software/plplot/installcmake/lib -lplplot

software@raven> pkg-config --libs --static plplot
-L/home/software/plplot/installcmake/lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9 -lplplot -lltdl -lm -lshp
-lfreetype -lcsirocsa -lcsironn -lqhull -lqsastime -lstdc++ -lm -lc

So for the static case we do (correctly) add in -lshp (and the rest)
because the plplot core library depends on all those libraries (for
example -lshp allows PLplot to handle maps (e.g., for standard example 19)
using the shapelib capabilities) so they have to be specifically
mentioned when linking to the static version of libplplot.

So there should be no bug for you to deal with in this modern case
(and for 5.12.0, I believe).

The only case where -lshp should not be included in the static link
line is if the PLplot build system does not find libshp.so (or
libshp.a) in which case the PLplot core library map capability falls
back to a much less useful and therefore deprecated map format.
So that is a situation to be avoided by installing libshp whenever
possible.

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
__________________________

[Plplot-devel] Install location logic substantially updated

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

On 2017-07-13 09:12+0200 Ole Streicher wrote:

> Another point is that TCLDIR is currently set to
> /usr/share/plplot5.12.0/tcl, which is not in the package path for
> Tcl/Tk. Is there a way to change this to something like
> /usr/share/tcltk/plplot5.12.0 [1] with a cmake option so that I
> don't need a patch here?

To Ole and Orion:

@Both:

Ole's question (and I think Orion had similar concerns in the past)
inspired me to "open a can of worms" which was to substantially update
how we configured our install locations (see last 4 commits ending
with 4c90970).

Most of the previous relevant build system code was inspired by
autotools and has been untouched for a decade so I decided to rework a
lot of it after using a fairly elegant find .. grep stanza (see commit
message for commit 62e07d4 which is the most important commit
in this series) to determine a complete list of install
location variables (some mandatory, some optional) which are now
created and summarized consistently.

When I first implemented the original code I was quite concerned by
the user mess it would make if a user started changing install
locations inconsistently.  So the version of the code just prior
to this recent series of commits propagated that attitude and
therefore made it impossible to change many of the install-location
variables (e.g., TCL_DIR was unchangeable). But now I have decided to
allow users to change any of these variables any way they like.

So here is a recent summary (much longer than before because I found
many install location variables in our code that were not treated
consistently before) of our install location variables for the case where I
specified the -DTCL_DIR=/whatever1 cmake option.  This is taken
from the latest version of the cmake output:
_______________________________________________

Summary of CMake build system results for PLplot

Install location variables which can be set by the user.  N.B. These
variables are ordered by decreasing degree of generality, with the
_default_ values of the later ones in the list determined by the
values of variables earlier in the list.  So, for example, it is
usually sufficient in the vast majority of cases to just set
CMAKE_INSTALL_PREFIX, and the rest of these variables are adjusted
accordingly (at least for a fresh configuration), and it is rare
indeed that is is necessary for a user to set any variable here whose
name does not start with "CMAKE_INSTALL_".

CMAKE_INSTALL_PREFIX: /home/software/plplot/installcmake
CMAKE_INSTALL_EXEC_PREFIX: /home/software/plplot/installcmake
CMAKE_INSTALL_BINDIR: /home/software/plplot/installcmake/bin
CMAKE_INSTALL_DATADIR: /home/software/plplot/installcmake/share
CMAKE_INSTALL_LIBDIR: /home/software/plplot/installcmake/lib
CMAKE_INSTALL_INCLUDEDIR: /home/software/plplot/installcmake/include
CMAKE_INSTALL_INFODIR: /home/software/plplot/installcmake/share/info
CMAKE_INSTALL_MANDIR: /home/software/plplot/installcmake/share/man
CMAKE_INSTALL_PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig
DATA_DIR: /home/software/plplot/installcmake/share/plplot5.12.0
LIB_DIR: /home/software/plplot/installcmake/lib
INCLUDE_DIR: /home/software/plplot/installcmake/include/plplot
BIN_DIR: /home/software/plplot/installcmake/bin
DRV_DIR: /home/software/plplot/installcmake/lib/plplot5.12.0/drivers
DOC_DIR: /home/software/plplot/installcmake/share/doc/plplot
INFO_DIR: /home/software/plplot/installcmake/share/info
MAN_DIR: /home/software/plplot/installcmake/share/man
PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig
FORTRAN_MOD_DIR: /home/software/plplot/installcmake/lib/fortran/modules/plplot
JAR_DIR: /home/software/plplot/installcmake/share/java
JAVAWRAPPER_DIR: /home/software/plplot/installcmake/lib/jni
PYTHON_INSTDIR: /home/software/plplot/installcmake/lib/python3.4/site-packages
PLPLOT_OCTAVE_DIR: /home/software/plplot/installcmake/share/plplot_octave
OCTAVE_M_DIR: /home/software/plplot/installcmake/share/octave/site/m/PLplot
OCTAVE_OCT_DIR: /home/software/plplot/installcmake/lib/octave
TCL_DIR: /whatever1
CMake Warning at cmake/modules/summary.cmake:44 (message):
   TCL_DIR = /whatever1 has prefix inconsistency with CMAKE_INSTALL_PREFIX =
   /home/software/plplot/installcmake
Call Stack (most recent call first):
   CMakeLists.txt:277 (summary)

ADA_INCLUDE_DIR: /home/software/plplot/installcmake/share/ada/adainclude/plplotada
ADA_LIB_DIR: /home/software/plplot/installcmake/lib/ada/adalib/plplotada
LUA_DIR: /home/software/plplot/installcmake/lib/lua/5.2/plplot
OCAML_INSTALL_DIR: /home/software/plplot/installcmake/lib/ocaml

Other important CMake variables:
[....]
_______________________________________________

So the user now has complete freedom to make a mess by attempting
to specify inconsistent install location variables, but I am hoping
there won't be too many of such messes because they are warned above in the preamble of the
above section of cmake output how to avoid that situation, and they
are warned afterward (but not stopped if they are insistent on
shooting themselves in the foot) at least for the egregious case of
using inconsistent install prefixes for any of these variables as
in this example with TCL_DIR: /whatever1

The above commit was rather intrusive so I gave it a complete
noninteractive and interactive comprehensive test which passed with
only minor dashboard submission issues (see the commit message for
commit 62e07d4 for the details) which I have since fixed.

However, our comprehensive tests do not test the

make DESTDIR=<location of staging area> install

trick used by packagers.  So I would appreciate you doing that
and checking to see if this series of commits has introduced any
problems.

Also, please take a look at the documentation of each of the
cached variables above which appears in CMakeCache.txt in
the build tree, and also let me know if you would prefer any
of the above default values to change.

@Orion:

In particular, does Fedora have policy about where *.tcl files should be
installed that is consistent with Debian policy about that?

The reason I ask is if there is some consensus on that question I
would likely change the default value of TCL_DIR 
from /usr/share/plplot5.12.0/tcl to that consensus.

@Both:

Also note, that when our build system was first put together in the
autotools era, Rafael insisted on using versioned plplot names
throughout, (e.g, /usr/share/plplot5.12.0)  so I have stuck with that since.  But I
am not as keen on that as he was so if your consensus (if it exists)
for the TCL_DIR default is unversioned, e.g.,

/usr/share/tcltk/plplot

that would be fine with me.

@Ole:

You sure do ask interesting questions.  :-)

Seriously, though, keep them coming since such
questions play an important role in improving
PLplot as in these last few commits.

As far as I can remember, this current answer from me only leaves the
spelling issues reported by lint (and you) that I need to answer, but
can you recall any further topic between us that I still need to answer?

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
__________________________

Re: [Plplot-devel] Install location logic substantially updated

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

On 2017-07-22 01:59-0700 Alan W. Irwin wrote:

[...]
> The above commit was rather intrusive so I gave it a complete
> noninteractive and interactive comprehensive test which passed with
> only minor dashboard submission issues (see the commit message for
> commit 62e07d4 for the details) which I have since fixed.
>
> However, our comprehensive tests do not test the
>
> make DESTDIR=<location of staging area> install
>
> trick used by packagers.  So I would appreciate you doing that
> and checking to see if this series of commits has introduced any
> problems.

To Ole and Orion:

I have just tried testing the use of DESTDIR as above by hand. As
expected, all files were installed in the staging area rather than the
designated install location.  I then moved that staging area to the
designated install location and built the test_noninteractive and
test_interactive targets by hand for that location for both our
CMake-based build system for the installed examples, and our
traditional (Makefile + pkg-config) build system for the installed
examples.  All seemed well for these 4 tests.  So that is a reassuring
result concerning our install location relocatability.

However, I still encourage both of you to attempt to package our git
master branch since that not only tests the above capability, but also
tests the latest PLplot in other useful ways.

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
__________________________

Re: [Plplot-devel] Install location logic substantially updated

[<p.d...@gm...>]

Just to check Alan, the mention of grep and all th linux centric paths listed made me wonder how (if at all) this affects Windows builds?

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 22 July 2017 10:00
To: Ole Streicher; Orion Poplawski; PLplot development list
Subject: [Plplot-devel] Install location logic substantially updated

On 2017-07-13 09:12+0200 Ole Streicher wrote:

> Another point is that TCLDIR is currently set to
> /usr/share/plplot5.12.0/tcl, which is not in the package path for
> Tcl/Tk. Is there a way to change this to something like
> /usr/share/tcltk/plplot5.12.0 [1] with a cmake option so that I
> don't need a patch here?

To Ole and Orion:

@Both:

Ole's question (and I think Orion had similar concerns in the past)
inspired me to "open a can of worms" which was to substantially update
how we configured our install locations (see last 4 commits ending
with 4c90970).

Most of the previous relevant build system code was inspired by
autotools and has been untouched for a decade so I decided to rework a
lot of it after using a fairly elegant find .. grep stanza (see commit
message for commit 62e07d4 which is the most important commit
in this series) to determine a complete list of install
location variables (some mandatory, some optional) which are now
created and summarized consistently.

When I first implemented the original code I was quite concerned by
the user mess it would make if a user started changing install
locations inconsistently.  So the version of the code just prior
to this recent series of commits propagated that attitude and
therefore made it impossible to change many of the install-location
variables (e.g., TCL_DIR was unchangeable). But now I have decided to
allow users to change any of these variables any way they like.

So here is a recent summary (much longer than before because I found
many install location variables in our code that were not treated
consistently before) of our install location variables for the case where I
specified the -DTCL_DIR=/whatever1 cmake option.  This is taken
from the latest version of the cmake output:
_______________________________________________

Summary of CMake build system results for PLplot

Install location variables which can be set by the user.  N.B. These
variables are ordered by decreasing degree of generality, with the
_default_ values of the later ones in the list determined by the
values of variables earlier in the list.  So, for example, it is
usually sufficient in the vast majority of cases to just set
CMAKE_INSTALL_PREFIX, and the rest of these variables are adjusted
accordingly (at least for a fresh configuration), and it is rare
indeed that is is necessary for a user to set any variable here whose
name does not start with "CMAKE_INSTALL_".

CMAKE_INSTALL_PREFIX: /home/software/plplot/installcmake
CMAKE_INSTALL_EXEC_PREFIX: /home/software/plplot/installcmake
CMAKE_INSTALL_BINDIR: /home/software/plplot/installcmake/bin
CMAKE_INSTALL_DATADIR: /home/software/plplot/installcmake/share
CMAKE_INSTALL_LIBDIR: /home/software/plplot/installcmake/lib
CMAKE_INSTALL_INCLUDEDIR: /home/software/plplot/installcmake/include
CMAKE_INSTALL_INFODIR: /home/software/plplot/installcmake/share/info
CMAKE_INSTALL_MANDIR: /home/software/plplot/installcmake/share/man
CMAKE_INSTALL_PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig
DATA_DIR: /home/software/plplot/installcmake/share/plplot5.12.0
LIB_DIR: /home/software/plplot/installcmake/lib
INCLUDE_DIR: /home/software/plplot/installcmake/include/plplot
BIN_DIR: /home/software/plplot/installcmake/bin
DRV_DIR: /home/software/plplot/installcmake/lib/plplot5.12.0/drivers
DOC_DIR: /home/software/plplot/installcmake/share/doc/plplot
INFO_DIR: /home/software/plplot/installcmake/share/info
MAN_DIR: /home/software/plplot/installcmake/share/man
PKG_CONFIG_DIR: /home/software/plplot/installcmake/lib/pkgconfig
FORTRAN_MOD_DIR: /home/software/plplot/installcmake/lib/fortran/modules/plplot
JAR_DIR: /home/software/plplot/installcmake/share/java
JAVAWRAPPER_DIR: /home/software/plplot/installcmake/lib/jni
PYTHON_INSTDIR: /home/software/plplot/installcmake/lib/python3.4/site-packages
PLPLOT_OCTAVE_DIR: /home/software/plplot/installcmake/share/plplot_octave
OCTAVE_M_DIR: /home/software/plplot/installcmake/share/octave/site/m/PLplot
OCTAVE_OCT_DIR: /home/software/plplot/installcmake/lib/octave
TCL_DIR: /whatever1
CMake Warning at cmake/modules/summary.cmake:44 (message):
   TCL_DIR = /whatever1 has prefix inconsistency with CMAKE_INSTALL_PREFIX =
   /home/software/plplot/installcmake
Call Stack (most recent call first):
   CMakeLists.txt:277 (summary)

ADA_INCLUDE_DIR: /home/software/plplot/installcmake/share/ada/adainclude/plplotada
ADA_LIB_DIR: /home/software/plplot/installcmake/lib/ada/adalib/plplotada
LUA_DIR: /home/software/plplot/installcmake/lib/lua/5.2/plplot
OCAML_INSTALL_DIR: /home/software/plplot/installcmake/lib/ocaml

Other important CMake variables:
[....]
_______________________________________________

So the user now has complete freedom to make a mess by attempting
to specify inconsistent install location variables, but I am hoping
there won't be too many of such messes because they are warned above in the preamble of the
above section of cmake output how to avoid that situation, and they
are warned afterward (but not stopped if they are insistent on
shooting themselves in the foot) at least for the egregious case of
using inconsistent install prefixes for any of these variables as
in this example with TCL_DIR: /whatever1

The above commit was rather intrusive so I gave it a complete
noninteractive and interactive comprehensive test which passed with
only minor dashboard submission issues (see the commit message for
commit 62e07d4 for the details) which I have since fixed.

However, our comprehensive tests do not test the

make DESTDIR=<location of staging area> install

trick used by packagers.  So I would appreciate you doing that
and checking to see if this series of commits has introduced any
problems.

Also, please take a look at the documentation of each of the
cached variables above which appears in CMakeCache.txt in
the build tree, and also let me know if you would prefer any
of the above default values to change.

@Orion:

In particular, does Fedora have policy about where *.tcl files should be
installed that is consistent with Debian policy about that?

The reason I ask is if there is some consensus on that question I
would likely change the default value of TCL_DIR 
from /usr/share/plplot5.12.0/tcl to that consensus.

@Both:

Also note, that when our build system was first put together in the
autotools era, Rafael insisted on using versioned plplot names
throughout, (e.g, /usr/share/plplot5.12.0)  so I have stuck with that since.  But I
am not as keen on that as he was so if your consensus (if it exists)
for the TCL_DIR default is unversioned, e.g.,

/usr/share/tcltk/plplot

that would be fine with me.

@Ole:

You sure do ask interesting questions.  :-)

Seriously, though, keep them coming since such
questions play an important role in improving
PLplot as in these last few commits.

As far as I can remember, this current answer from me only leaves the
spelling issues reported by lint (and you) that I need to answer, but
can you recall any further topic between us that I still need to answer?

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
__________________________

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Install location logic substantially updated

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

On 2017-07-22 11:42+0100 p.d...@gm... wrote:

> Just to check Alan, the mention of grep and all th linux centric
paths listed made me wonder how (if at all) this affects Windows
builds?

Hi Phil:

The find and grep commands were simply used to discover (hopefully)
all of the install location variables we potentially use in our source
tree for all platforms.  So you should have no platform concerns about
how I made that list of variables.

However, I do emphasize this is an intrusive change that needs testing
on all platforms to make sure I did not introduce any
platform-dependent problems by accident.

To start that testing process I did such testing for my combination of
Windows native CMake (version 3.8.2 downloaded in
binary form directly from KitWare), Wine-staging-2.10, and ancient (4.7.2)
version of MinGW/MSYS for the "MSYS Makefiles" generator.

For the cmake command-line options

-DCMAKE_INSTALL_PREFIX:PATH=/z/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging
-DFORTRAN_MOD_DIR:PATH='Z:\whateveR\dire ctorY'

(the single quotes are to protect the backslashes and space in that
string from interpretation or processing by bash.exe) the selected
cmake ouput results are
as follows:

[...]
name does not start with "CMAKE_INSTALL_".

CMAKE_INSTALL_PREFIX: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging
CMAKE_INSTALL_EXEC_PREFIX: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging
CMAKE_INSTALL_BINDIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/bin
CMAKE_INSTALL_DATADIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/share
CMAKE_INSTALL_LIBDIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/lib
CMAKE_INSTALL_INCLUDEDIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/include
CMAKE_INSTALL_INFODIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/share/info
CMAKE_INSTALL_MANDIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/share/man
CMAKE_INSTALL_PKG_CONFIG_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/lib/pkgconfig
DATA_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/share/plplot5.12.0
LIB_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/lib
INCLUDE_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/include/plplot
BIN_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/bin
DRV_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/lib/plplot5.12.0/drivers
DOC_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/share/doc/plplot
INFO_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/share/info
MAN_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/share/man
PKG_CONFIG_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/lib/pkgconfig
FORTRAN_MOD_DIR: Z:/whateveR/dire ctorY
CMake Warning at cmake/modules/summary.cmake:44 (message):
   FORTRAN_MOD_DIR = Z:/whateveR/dire ctorY has prefix inconsistency with
   CMAKE_INSTALL_PREFIX =
   z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging
Call Stack (most recent call first):
   CMakeLists.txt:277 (summary)

ADA_INCLUDE_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/share/ada/adainclude/plplotada
ADA_LIB_DIR: z:/home/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/lib/ada/adalib/plplotada

Other important CMake variables:
[...]

Note, the above list of variables and values is shorter than what I
published for the Linux case because this platform provides few soft
dependencies for PLplot so many of the optional install-location
variables are not set.

The above output values of install-location variables have no specific
path transformations done by the CMake logic in our build system.
Therefore, those output results reflect whatever path transformations
are applied _by default_ by CMake to 
"-D<variable_name>:PATH=<value>" user-input values, e.g.,
CMAKE_INSTALL_PREFIX and FORTRAN_MOD_DIR in the above case.

So you can from this example, that this Windows native version of
CMake converts all input :PATH value formats to the native CMake
format for :PATH values. That transformation leaves case the same as
input (which is good because some Windows platforms provide
case-sensitive filenames), converts the slash form of drive letters to
the colon form (e.g., CMAKE_INSTALL_PREFIX) and converts backwards
slashes to forward slashes (e.g., FORTRAN_MOD_DIR).  And further
experiments showed that if the input value of a :PATH variable was in
the native CMake format for :PATH values, no transformation was done
to that value at all.  Note the values of these variables that are not
specified by the user are generally derived by appending sensible
defaults (in forward slash form) to :PATH prefixes (e.g.,
CMAKE_INSTALL_PREFIX) higher in the list that have been specified by
the user.  So the net result is all these internal CMake values are in
native CMake format for :PATH values.  As a result, we appear to have
the ideal case that if a Windows platform user wants to modify any of
the above results he can do so using exactly the same native CMake
:PATH variable format as is output above, but users are
also allowed to use other input formats for :PATH variables.

If there is a prefix inconsistency the user is warned of that (as in
FORTRAN_MOD_DIR above) but our build system continues on despite that
inconsistency, i.e., the files installed using the particular
install-location variable that uses an inconsistent prefix will be
installed in that inconsistent location.  And I have confirmed the
user gets this warning even if it is only a case-sensitive prefix
inconsistency, e.g., the upper-case "E" in /homE below

-DFORTRAN_MOD_DIR:PATH=z:/homE/wine/wine_staging/build_results/install-2.10_jessie_wine_staging/whatever

I contemplated making the prefix comparison with
${CMAKE_INSTALL_PREFIX} in a case insensitive way to avoid this kind
of warning but I thought better of it after my google search told me
there are windows platforms out there where a registry change can make
filenames (and I assume directory and drive-letter names) case
sensitive. However, as a result of the case-sensitive comparison in
the present logic, if a user specifies a prefix for the value of one
of the install-location variables that differs only in case from
${CMAKE_INSTALL_PREFIX}, they will get the warning which will be
spurious.  However, detecting whether Windows is case sensitive or not is
likely a nightmare, there is no harm from this spurious warning for
case-insensitive windows, and it is easy enough for the user to quiet
this warning by specifying exactly (including case) consistent
install prefixes.

@Everybody:

So I have pretty much come to the end of the tests I can apply for
this change both on Linux and Windows, and I am satisfied with those
results.  However, I repeat it has been an intrusive change so the
Windows users here should try some equivalent experiments to what I
tried above for their favorite generator just to make sure for that
generator that all input :PATH variables are translated to internal
format for any of such variables that are output in the cmake summary
(and in CMakeCache.txt), and that internal format is also suitable for
:PATH variable input.

Of course, much more extensive testing than such limited experiments
would be extremely useful as well leading up to our release so Arjen's
efforts to make on-going runs of scripts/comprehensive_test.sh for at
least the noninteractive case for Cygwin, MinGW-w64/MSYS2, and MSVC (+
the Unix tools on PATH trick that Arjen got working recently) are most
appreciated.  Of course, it is important for others lurking on this
list to participate in such important tests as well to make sure all
your own variants of Windows and Linux platforms are covered by such
testing (and to insure at least one variant of Mac OS X is covered by
our testing).  So please contact me if you are interested in adding
yourself to the comprehensive testing team for PLplot, and we can take
it from there.

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
__________________________

Re: [Plplot-devel] Install location logic substantially updated

[Ole S. <deb...@li...>]

Hi Alan,

On 22.07.2017 10:59, Alan W. Irwin wrote:
> So the user now has complete freedom to make a mess by attempting
> to specify inconsistent install location variables

I am very happy with that freedom :-) Thank you for these changes.

> @Orion:
> 
> In particular, does Fedora have policy about where *.tcl files should be
> installed that is consistent with Debian policy about that?
> 
> The reason I ask is if there is some consensus on that question I
> would likely change the default value of TCL_DIR from
> /usr/share/plplot5.12.0/tcl to that consensus.

One comment here: Debian has both the /usr/lib/tcltk and
/usr/share/tcltk paths usable; first for the architecture dependent
files (in an arch dependent subdir), second for architecture independent
files. This is, however, mostly to save space on multi-arch systems
(i686 and x64); as long as there are no tens of megabytes, I have no
objections to put everything together into /usr/lib/tcltk/<arch>/.
However, whatever goes into /usr/share/, must be truly arch independent.

> @Both:
> 
> Also note, that when our build system was first put together in the
> autotools era, Rafael insisted on using versioned plplot names
> throughout, (e.g, /usr/share/plplot5.12.0)  so I have stuck with that
> since.  But I
> am not as keen on that as he was so if your consensus (if it exists)
> for the TCL_DIR default is unversioned, e.g.,
> 
> /usr/share/tcltk/plplot
> 
> that would be fine with me.

Both is fine with me. We don't allow multi-version installations, so it
finally does not matter.

> @Ole:
> 
> You sure do ask interesting questions.  :-)
> 
> Seriously, though, keep them coming since such
> questions play an important role in improving
> PLplot as in these last few commits.
> 
> As far as I can remember, this current answer from me only leaves the
> spelling issues reported by lint (and you) that I need to answer, but
> can you recall any further topic between us that I still need to answer?

Not for the moment. The current Debian release (5.10.0) has some minor
multi-arch issues, but they seem to be a problem of the old packaging. I
think with the simplified packaging, this will go away.

It may be however be useful if you could create a "release candicate"
(or beta) tarball, and give some time to test it. I could create a
Debian package out of that and upload to our "experimental" branch.
While you do probably not want to wait until it builds on all platforms
(it has to go through review of our ftp-masters), I can do some tests
locally and report back (but please, give some time; it is holiday
season :-) )

Best regards

Ole

Re: [Plplot-devel] Install location logic substantially updated

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

On 2017-07-22 15:07+0200 Ole Streicher wrote:

> It may be however be useful if you could create a "release candicate"
> (or beta) tarball, and give some time to test it. I could create a
> Debian package out of that and upload to our "experimental" branch.
> While you do probably not want to wait until it builds on all platforms
> (it has to go through review of our ftp-masters), I can do some tests
> locally and report back (but please, give some time; it is holiday
> season :-) )

Hi Ole:

I doubt I will bother with a release candidate.  But we all make
a pretty strong effort to keep the git master branch in good shape,
and the current tip of the master branch (i.e.,

4c90970 Build system: Quiet cmake developer warning

) is especially well tested.  So I suggest
you use that commit or later for your ongoing testing of
the development version of PLplot.

Of course, that commit is not a formal release candidate.  For
example, the version numbers (library SONAMEs as well as overall
version) have not been upgraded yet, and that will only happen some
time after our source code freeze and the associated review of the git
log to see what changes have been made since 5.12.0.  But the point is
this well-tested version is much closer to 5.13.0 than 5.12.0 so if
you fix all the issues for this development version (with me attending
to some of them upstream like the install location issues I just
addressed) you will likely have very little left to do on the Debian
packaging front when 5.13.0 is officially released.

Probably more important still, this is a relatively good time for me
to make upstream changes based on your experience with the developer
version of PLplot, but my willingness to implement such changes is
going to rapidly decrease (i.e., I will likely put you off until
post-release unless you have found something absolutely release
critical) as we move closer to the release.

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
__________________________