Re: [Plplot-general] CMake problem with hyphen in path

[Alan W. I. <Ala...@gm...>]

On 2019-07-12 09:10+0100 Phil Rosenberg wrote:

[...]
> I couldn't work out the full purpose of the function cmake_link_flags
> yesterday, but I've just sat and looked again. My understanding is
> that it's primary purpose is to take liker flags -L and -l, specifying
> library directories and library names, then use find_library to
> actually locate each library and get the full path to that library.
> The -L and -l flags are therefore replaced by the full path.
>
> I think the splitting of flags with semicolons is what is known as a
> side-effect (https://softwareengineering.stackexchange.com/questions/40297/what-is-a-side-effect),
> or maybe against the "principle of least surprise", or some other
> programming mantra. Anyway, I think the "bug" is that this function
> should not be responsible for splitting flags, it should only convert
> flags to paths.
>
> I think the best way to proceed would be to have a function which
> splits flags, and we only pass flags to it (not paths), then this
> function which deals with can deal with flags and paths without
> worrying about delimiters.

> Thoughts?

Hi Phil:

Thanks for your interest in helping me figure out this particular hyphen issue.

The string parsing transformation logic in question is

string(REGEX REPLACE " -" ";-" _link_flags_list "${_link_flags_in}")

(See <https://cmake.org/cmake/help/latest/command/string.html> which
includes documentation of the REGEX REPLACE form of the string
command.)  So the logic here is to transform each blank delimited
link option (where each such option starts with a hyphen) into a
semicolon-delimited link option where that delimiter means the
string can be further interpreted (later in the macro) as a CMake list with elements
which are link options.

The above string logic
correctly ignores unhyphenated blanks
within -L options (i.e, just treats those blanks as part of the directory name referred to by
the -L option).  However, the logic obviously fails for your test case
where you have " - " embedded
within -L options.

I am pretty sure from the above documentation that replacing
the above logic with

string(REGEX REPLACE " -([^ ])" ";-\\1" _link_flags_list "${_link_flags_in}")

should address this issue.  But this fix is too specialized for
general use because the logic still breaks if the hyphen within the -L
option is followed by a non-blank character.

For example, the option string being parsed could be

"-Lfirst_string -Lsecond_string"

Are there two -L options here referring to the directory names "first_string" and "second-string" or is
there just one -L option here referring to the directory name "first_string -Lsecond_string"?

I am virtually positive pkg-config has a way (likely with quotes) to
properly distinguish between these two cases, but I am going to have
to find what that is and adjust the above parsing logic accordingly
for the general fix.

Hopefully most of the other hyphen issues that showed up in the Linux case will be much
easier to fix than this particular issue.

Alan
__________________________
Alan W. Irwin

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.org); 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
__________________________