Matthew Woehlke

When were INTERFACE libraries introduced to CMake? They were in 3.0, according to the doc: see https://cmake.org/cmake/help/v3.0/command/add_library.html (hiding at the bottom). If you really still need pre-3.0 support, the easiest is probably to just omit the INTERFACE library when built with pre-3.0 CMake and require those users to use the variables. (FWIW, 3.0 is almost four years old now... June 9, 2014.) How does the end-user (linking her code with GeographicLib) get to specify whether to use...

Patch, as promised. There's wiggle room in the target and variable names used, but this should at least demonstrate the suggested approach. This is also being tested by https://github.com/Kitware/fletch/pull/376.

Sorry, I don't know of any examples. There aren't all that many projects that build separate static and shared libraries in the first place; it's more common to just build one library with the same name, that is either static or shared based on BUILD_SHARED_LIBS. That said, I talked with (CMake developer) Brad King and he agrees it is preferable for consumers to be able to use a target name (not ${GeographicLib_LIBRARIES; "that's old style") without needing to care which flavor(s) of library are...

I recently modified one of my projects¹ to use GeographicLib imported target names, as this is generally preferred in modern CMake. However, this is now failing on Windows, because GeographicLib is by default built static there, and the target names are different. Is it intended that GeographicLib requires use of the old-style variables for linking and is not friendly to using the target names directly? Or is there hope that this could be improved? One idea that comes to mind is to rename the shared...

get_parser_class problems loading parsers from other modules

(Great, I don't get any notification of replies? Grr... sorry for the delay...) This...

Trying to build PythonQt with g++ 4.8.3 using -std=c++11 results in build errors...