Newer versions of MacOS require linking against *.tbd files and not old system paths to *.dylib

[ben.boeckel (Ben Boeckel (Kitware))]

@tye59

I’m looking through the cmake documentation and wonder if I’m missing some use of INTERFACE, PUBLIC or PRIVATE vars that could expose the shorthand notation (-lm) or expanded system library paths before they get written into the build.make, link.txt or project files.

Whichever project is hardcoding m to the list of link libraries should instead migrate to using imported targets instead to represent them. Something like this:

add_library(MyProject::libm UNKNOWN IMPORTED)
set_target_properties(MyProject::libm PROPERTIES IMPORTED_LIBNAME m)

Repeat for other system libraries as needed. This would need to be replicated to the -config.cmake file to make it available there too. This should abstract away the path between the build and consuming environments.

Unsolicited observation and advice on the situation as a whole though (as a complete outside observer). Feel free to ignore . I don’t think I’ll change anyone’s mind, but hopefully it’s something to think about for future projects.

@tye59

Our scientific user base is not in a hurry to upgrade to the latest Apple OS or upgrade to the latest release of our software until they are done with what could be years of research. Changing the OS that runs or the compilers that built our code means new floating point results may not be consistent with previous statistical analyses

It would seem to me that then choosing macOS as a base for which you cannot move for years would be inconvenient for research? How is anything supposed to be reproducible by anyone not keeping a couple un-updated Apple hardware devices stashed in a closet somewhere?