On 2017-07-22 11:42+0100 p.d.rosenb...@gmail.com 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
__________________________
------------------------------------------------------------------------------
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
