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
__________________________
_______________________________________________
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general
