Discussion regarding creating an open macOS SDK package.

I think no one wants to tell people to use old macOS’s or download stuff from people with hackery sounding usernames on github, at least I do not.

Now that https://github.com/conda-forge/staged-recipes/pull/9557 has happened, we should be able to allow end-users to use their system SDKs via CONDA_BUILD_SYSROOT, but that’s not ideal for ABI reasons.

But I think we should provide our own SDKs. The official SDKs are an amalgamation of various mostly BSD licensed projects (mach-o kernel, dyld, a few more). I think we can now generate .tbd files from Apple’s .dylibs and we can also ‘whiteroom’ that if people are concerned - you literally get one person to describe, via voice, the functions and their prototypes! - but personally I’m not really very concerned. So I think, given a simple bash script we could make something we can use and recommend to our users.

cc @conda-forge/core, @chrisburr (you’re in core anyway I guess, but just in case), @katietz, @msarahan.

[scopatz]

Wow what a mess.

1. .h, .defs, .r, .x - We need to be careful here and make sure each is actually open source, preferably sourcing them from upstream packages if possible.
2. .tbd - Let’s regenerate
3. .modulemap, .map - Let’s ignore if there for the moment.
4. .o - I actually doubt we can redistribute object files unless they are open source.
5. pkg-config - again we need to be careful and double check.
6. .plist - are they needed?
7. .apinotes, .rb - yep let’s ignore
8. .a - we are trying to move away from static libraries anyway, so it is probably a good idea to ignore

[mingwandroid]

We should also think about XQuartz development packages unless conda-forge has detached from all XQuartz dependencies entirely? If we package XQuartz we could make it depend on an SDK package and use a symlink to impose it into those SDK hierarchies.