Thanks Alan for confirming things see below Can I check what the logic is for splitting the paths
On Fri, 12 Jul 2019 at 01:16, Alan W. Irwin <alan.w.irwin1...@gmail.com> wrote: > > On 2019-07-11 15:05-0700 Alan W. Irwin wrote: > > > I decided to attempt a somewhat equivalent step (iv) on Linux by setting the > environment variables > > CMAKE_INCLUDE_PATH="/usr - hyphen/include" > > and > > CMAKE_LIBRARY_PATH="/usr - hyphen/lib:/usr - hyphen/lib/x86_64-linux-gnu" > > where "/usr - hyphen" is a symlink to /usr. The result is CMake finds > most (but not all which I have to debug) external headers and > libraries in the "/usr - hyphen" tree, and those headers and libraries > trigger both configuration errors and build errors which confirms in > general form the PLplot build-system issue that Phil discovered. > glad you were able to recreate the bug > Based on prior experience the fix for such issues is often simply to > quote the relevant strings used in our CMake logic. So I expect this > project will be a long one but still pretty straightforward, and I > plan to take responsibility for it. However, after I have gone as far > as I can go on the Linux side this summer, it would be great both of > you would be willing to at least comprehensively test the result on > MSYS2 with special install prefix to see if there are any remaining > blank or hyphen issues left on that platform. So please do go through > steps (i) through (iii) and standby (until I am done on the Linux > side) for step (iv) above. I am not sure about the logic behind the regex replace that I pointed out in my first email. I presume it is there to separate flags from space delimited into semicolon delimited, making it a CMake list/array. I think that the way to do this therefore must be to pass linker flags only and not libraries. We are conflating the two. Whatever logic we use to distinguish a flag from a library path, someone somewhere will end up with a path that breaks that logic. 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? Phil I will try and m > > 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