On 2018-02-12 23:06+0100 Mario Emmenlauer wrote:

On 12.02.2018 22:09, Alan W. Irwin wrote:
[...]
I am virtually positive from reading
<https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other
MinGW-w64/MSYS2 documentation that the conversion from POSIX to native
PATHs is done by the MSYS2 dll.  Also, MinGW-w64/MSYS2 applications
from the msys2 repository are linked against that dll while the
applications from the mingw64 repository are pure native, i.e., not
linked against that dll.  Thus, if that mental model is correct, here
are some predictions that flow from it.

* The cmake version from the msys2 repository will understand cache
variables expressed as POSIX PATHs, but the cmake version from the
mingw64 repository wont have that capability.

I am not sure if I follow until here, but very likely I just misunderstand
what you are saying. Please help shed some light!

I will try.  :-)

In my observation, I
have cmake installed from mingw64 repository, and I can successfully use
this cmake with a CMAKE_PREFIX_PATH in POSIX PATH notation
find all my dependencies with find_xxx() commands (i.e. find_library() or
find_file() or the like). I also use this same cmake with a path to the
source directory specified as POSIX PATH.

So to be 150% sure we mean the same, the following works for me, where
/d/ corresponds to the D: drive of Windows:
   /mingw64/bin/cmake /d/tmp/sources \
       -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
   make && make install

Is that contradictory to your point above?

It certainly contradicts one of my predictions.

Just to clarify, the environment variable form of the above command
would have been (assuming your command-line environment is bash.exe
from the msys2 repository of MinGW-w64/MSYS2)

export CMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
/mingw64/bin/cmake /d/tmp/sources && make && make install

But instead, of using that environment variable form of the
command you used the
-DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
cmake option which sets CMAKE_PREFIX_PATH as a cache variable.

And for that cache variable approach, my prediction was the mingw64
version of cmake would not work with the above POSIX form of
CMAKE_PREFIX_PATH, but your experience is it does work!  So that
contradiction to the prediction is indeed an interesting result.

Just to cover off one possibility, could you try the bash printenv
command to print out all your bash environment variables to make sure
you have not inadvertently set the environment variable form of
CMAKE_PREFIX_PATH?  Of course, if you confirm this way that
CMAKE_PREFIX_PATH is not set as an environment variable, then it is
pretty clear something is incorrect/incomplete about the above mental
model.

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
__________________________
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Reply via email to