Re: [Plplot-devel] Space in full pathname issues

[Arjen M. <Arj...@de...>]

Hi Alan,



See my remarks in context.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, May 09, 2017 10:10 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Space in full pathname issues
>
> On 2017-05-09 11:31-0000 Arjen Markus wrote:
>
> > Hi Alan,
>
> Hi Arjen:
>
> The CMake developers have been notoriously lax concerning how the cmake
> command parses its command-line arguments.  So when there is some error in that
> parsing you do often get a hang. But I would strongly advise you when that
> happens to not let it run more than a minute or two (i.e., the maximum time that
> cmake normally takes to configure PLplot).  After all, with a hang, there is some
> indefinite loop happening, and if there are any memory leaks in that loop you could
> end up with an out-of-memory error and take down your whole system!
>

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.

> That said, whatever the quirks in cmake command-line processing, those quirks
> should be consistent for a given version of CMake (unless the guy that packages
> CMake for Cygwin has applied a specific patch to have unique command-line
> processing for the Cygwin version of CMake which in my opinion would be a huge
> mistake on his part.)  Up to now all my space in pathname checking has been done
> from the bash shell and for CMake-3.7.2.
>
> To check whether you are also running the bash shell, what is the result of the
> "echo $0" command there?  Here it is
>
> software@raven> echo $0
> /bin/bash
>
I get an unexpected "-bash". So, bash, but slightly different ...

> If you get an empty response or a non-bash response, please switch to the bash
> shell for your tests by simply executing the "bash" command.
>
> 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.

> For the record, here is what I did ...

>
> If the Kitware version works and the Cygwin one does not on Cygwin for the above
> form of the cmake command, then that is a clear bug in the Cygwin version that you
> should report to the Cygwin list, and meanwhile continue with the above experiment
> using the Kitware version (contrary to how I have argued before since my
> assumption was any patches added by the Cygwin packager would add some value
> for this platform rather than introducing a bug).
>
> Of course, if both the Kitware version and Cygwin version of
> CMake-3.6.2 fail to work, then I assume the cause is some unknown Cygwin issue
> that is likely nothing to do with CMake or the bash shell.  In which case you really
> are stuck, and we have to emphasize in our wiki that blanks in the install prefix are
> simply not allowed by the Cygwin platform for unknown reasons.  But hopefully it is
> just a bug in the Cygwin version of cmake that can be worked around (until that bug
> is fixed) by using the Kitware CMake (or you were using a slightly different form
> than above, and in fact both the Kitware CMake and Cygwin CMake work if you use
> the exact form above).
>
Well, that will have to wait for me to build CMake on Cygwin from the sources. No time for that right now, I am afraid.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.