what say we just use MacOSX.sdk preferentially on BigSur and up?
Ken Cunningham
ken.cunningham.webuse at gmail.com
Fri Jan 1 17:38:18 UTC 2021
Happy New Year to all!
> On Dec 31, 2020, at 2:10 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> We want to avoid ports installing files that contain the specific SDK path. Some ports do so only for information so it doesn't matter. Others might use those values later to build other software, like maybe python recording the SDK path to use it to build python modules later. In those cases, we should replace the SDK path with the generic unversioned SDK path that exists on all systems.
OK, I can agree with this for sure, and I have already heard Chris and Michael say they do as well.
If that opinion holds up under scrutiny, we can start building all the gcc versions, perl, python, ruby, and all the others we might stumble across with the path to the unversioned MacOSX.sdk baked in, instead of what they do now.
How do we best identify, in a Portfile situation, the full path the MacOSX.sdk, would you suggest.
On which systems? 10.13 and up would be sensible, but we could say up to 10.14 are settled now and can left alone if you prefer.
> A similar problem is when build systems save the compiler that was used into files that get installed and then try to use that compiler later to build other modules; perl does this. And this causes problems like https://trac.macports.org/ticket/59786. The solution is the same: replace the specific compiler path in the installed files (e.g. /opt/local/bin/clang-mp-3.4) with the generic compiler (/usr/bin/cc) that exists on all systems.
I don’t imagine you really mean we should change the baked in compiler for for perl, python, ruby, and the like to /usr/bin/cc.
On some system versions, /usr/bin/clang perhaps?
> (The even better solution is to explain to those projects that they should stop saving the compiler name into their installed files and stop trying to use it later; instead, they should always obey the CC and CXX environment variables.)
>
totally agree here, and why exactly perl and the others bake in their build compiler is unclear to me, but causes headaches.
More information about the macports-dev
mailing list