On 2017-05-12 07:30-0000 Arjen Markus wrote:

> [For cmake] I tried the \ variant for incorporating spaces in an option - 
> same result, CMake hangs. However, I have found what it is doing: it writes a 
> file export_plplot.cmake.tmp which contains:
>
> ...
>
> # Compute the installation prefix relative to this file.
>
> get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
>
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
>
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
>
> ... (1.5 GB of such identical messages)
>
> I tried this with the Windows 3.6.2 version as well, that simply works as 
> expected. No problem with a hanging CMake. So it appears to be specific to 
> Cygwin.
>

> As Cygwin's CMake is tuned for that environment, I did not expect
success with the next experiment, using Windows' CMake, version 3.6.2,
on Cygwin. Nor was I proven wrong - that version of CMake can't find
the various tools, so it stops with a configuration error.

>> Just to make sure what you have encountered is not a quirk for
>> CMake-3.6.2 that has been fixed for 3.7.2, I tried CMake-3.6.2 here (built 
>> by me
>> from unpatched source code provided by Kitware using the bootstrap method on
>> Debian Jessie just like I build 3.7.2), and the above experiment worked fine.
>>
>
> I have not tried that method yet - might be an idea indeed. It is just a wee 
> bit more work.

To keep this organized, here is a summary of what you have discovered
so far:

(1) You have an infinite loop for any version of a "spaced" install prefix for 
the
Cygwin version of cmake.  I suggest you report that clear bug to the Cygwin
list and see what the response is.

(2) You don't have that infinite loop with the Kitware version of
Windows CMake, but there are find troubles with that version.

So for now (until (1) is solved) you could simply write off this
platform for the "spaced" install prefix case and document that
in our wiki.

However, there is another alternative which is to try an unpatched
CMake version that you have built for yourself on the Cygwin platform.
I believe there is a reasonable chance that experiment would work
since Cygwin does try to be POSIX compatible so the result you get
should be similar to the result I get on Linux which is no infinite
loop bug and CMake find works well.

So assuming you do want to pursue that experiment (once you have more
time) here are my notes on my bootstrap builds for Linux.  Note these
are close to instructions that might appear in a bash script, although
for now I just cut and paste these instructions on the bash command
line.

Note, these instructions assume you have used git clone to establish
a local git repository for CMake in a subdirectory called cmake.git.

______________________________________________________

# Choose whatever version you want to build:
export CMAKE_VERSION=3.8.1
TAG_VERSION=v${CMAKE_VERSION}
export CFLAGS='-O3'
export CXXFLAGS='-O3'

# Use current directory as convenient prefix directory for
# all directories below.
PREFIX_DIRECTORY=$(pwd)

# Update master branch of local repository
cd ${PREFIX_DIRECTORY}/cmake.git
git checkout release
git fetch
git merge --ff-only origin/release

# Optional: Check TAG_VERSION from local updated git repository
git tag --verify ${TAG_VERSION}

# Checkout TAG_VERSION from local updated git repository
git checkout ${TAG_VERSION}
mkdir -p ${PREFIX_DIRECTORY}/build_dir
cd ${PREFIX_DIRECTORY}/build_dir
# Use fresh start every time
rm -rf ${PREFIX_DIRECTORY}/build_dir/* 
${PREFIX_DIRECTORY}/install-${CMAKE_VERSION}
nice -19 ${PREFIX_DIRECTORY}/cmake.git/bootstrap \
--prefix=${PREFIX_DIRECTORY}/install-${CMAKE_VERSION} \
--parallel=8 --qt-gui --system-curl  >& bootstrap.out

nice -19 make -j8 >& make.out
nice -19 make -j8 install >& make_install.out

grep -i warning *.out
# N.B. currently there is a warning about COPY_ONLY (which should be
# COPYONLY) in
# /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreMacros.cmake:224.
# That file belongs to qtbase5-dev:amd64 whose version is
# 5.3.2+dfsg-4+deb8u1, but (see
# <https://bugreports.qt.io/browse/QTBUG-44637>) apparently this Qt5
# bug has been fixed in 5.4.1.

grep -i error *.out
# N.B. got errors at this stage until I installed libqt4-dev (and
# qt4-doc and qt4-dev-tools).
cd ${PREFIX_DIRECTORY}
# Optional
rm -f install
ln -s install-${CMAKE_VERSION} install
______________________________________________________

The above search for warnings and errors should guide you on what
additional packages you need to install.  However, from just
eyeballing the above, the git tag --verify command (although that is
optional it is always a good idea to run that command from the
security point of view) requires you to have the Cygwin gnugpg package
installed and you will also need the Cygwin curl development library
package (libcurl-devel) installed.  You likely already have the Cygwin
equivalent of the libqt[45]-dev Debian development package installed
as a PLplot prerequisite so I expect you will only need to install the
qt[45]-devel-tools and qt[45]-doc Cygwin packages in addition to get
rid of all warnings and errors in the above build.

Good luck with the above as a low-priority PLplot item, but for now I
would concentrate first on non-space MinGW-w64/MSYS2 issues (i.e.,
getting all PLplot prerequisites installed and working on that
platform), and getting the comprehensive test script to work on
non-space MSVC (+ MinGW-w64/MSYS2 unix tools) where I believe the
current issue stopping you is simply installing the diff unix tools.
Then once the non-spaced comprehensive testing is working properly on
both those platforms tentatively try the spaced version of the same
with the source, build, and install trees having spaces in their
prefix.

By the way, the status here is I am still far from done with that
"space" experiment on the Linux platform.  I have gotten most
components to work for the non-interactive case which is sufficient to
make it worth your while to try similar experiments on MinGW-w64/MSYS2
and MSVC (once the non-spaced comprehensive tests are working well on
those platforms). However, I am still working on some remaining
noninteractive "space" issues (e.g., an OCaml issue for the static
case, and language support issues for the Ada and D compilers), and I
haven't yet even tried any interactive "space" tests.

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

Reply via email to