[CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Alan W. Irwin]

On 2015-12-14 12:43-0000 Ray Donnelly wrote:

> The issue I've got here is that on MSYS2 we've decided that we don't
> want to provide libdl for mingw-w64 but do provide it for msys2, so
> there'll never be a /mingw{64,32}/lib/libdl.a or
> /mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When
> building mingw-w64 software, the front of PATH will be
> "/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes
> CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH.

Hi Ray:

Did you mean "due to NO_SYSTEM_ENVIRONMENT_PATH _not_ being set"? 
That is the only way that sentence makes sense to me and is also
consistent with the subject line, but I may be missing something.

So if my interpretation of what you said is correct, your special
build problem on the MinGW-w64/MSYS2 platform is you want to reject
msys2 variants of the libraries (thus avoiding a dependency on the
msys2 dll) while still using msys2 build tools.

Assuming I have stated the problem correctly, then the solution
normally is to put /mingw{64,32} first on your PATH (like the
appropriate shell does as you have discussed) and that should
guarantee the /mingw{64,32} version of the library is found.  However,
for the special case where there is no /mingw{64,32} version of the
library (from what you said above libdl is an example of this special
case) the CMake-based build systems will incorrectly find the msys2
version of the library (because msys2 is necessarily on the PATH
because you need access to those build tools) rather than your desired
result that CMake finds no library at all for this special case.

I believe the MinGW-w64/MSYS2 distribution should address this problem
in general by making sure that /mingw{64,32} does provide all
libraries that msys2 provides if at all possible.  However, whenever
there is some absolutely ironclad reason not to provide a
/mingw{64,32} variant (as appears to be the case for libdl although
you may want to review that reason to make sure it is really ironclad)
then you must patch all build systems for software packages that have
a soft dependency on libdl to simply ignore any libdl that is found on
the MinGW-w64/MSYS2 platform.  My impression is that build system
patches are required quite often for distributions of free software to
help enforce some policy decisions they have made so it appears that
MinGW-w64/MSYS2 is also not immune to such a requirement.  Of course,
this is not a very good solution if there are tonnes of such package
build systems to patch, but my guess is that patches for just a
handful of packages would be required to deal completely with this
special libdl case.

By the way, you will be glad to know that I have a strong spectator
interest in MinGW-w64/MSYS2 because it turns out (thanks to the
testing reports sent to me by Greg Jung which allowed me to adjust the
PLplot build system to work properly for the MinGW-w64/MSYS2 case)
that has recently become one of our most powerful and reliable PLplot
platforms on Windows.

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
__________________________