be more sophisticated about deriving configs from macOS variables

[stuij]

edit:
current commit message:

this patch is fixing two issues:

Currently when figuring out the toolchain package name, we make some wrong
assumptions like the presence of CMAKE_OSX_ARCHITECTURES means a unified
build. Also when CMAKE_OSX_ARCHITECTURES is not present and we are building on
macOS silicon, the package name will be `AArch64`.

Should do some parsing of the CMAKE_OSX_ARCHITECTURES and look at the
CMAKE_SYSTEM_PROCESSOR var, to deduce the right system name.

Basically when CMAKE_OSX_ARCHITECTURES is set and non-empty, this overrides the
system architecture, and we need to figure out if we do a unified build (both
x86_64 and arm64 are specified), or either.

If it's a unified build, use `unified` to make this clear, instead of the
current behaviour of omitting the arch string.

Another issue is that we use the presence of the CMAKE_OSX_ARCHITECTURES string
to infer if we should build a `.dmg` or not. Seeing the complexity around
CMAKE_OSX_ARCHITECTURES, it's better to just use CMAKE_SYSTEM_NAME, which would
always point to `Darwin`"

[stuij]

I'll redo this patch in the next few days to do better OSX input checking. Currently in the CMakeLists.txt file ‘CMAKE_OSX_ARCHITECTURES’ is used as a synonym for universal library, which it isn’t. Users can of course put whatever they like in it, and I think it’s totally ignored when used on a non-Apple arch. It's very common to just put the system arch of the build machine in there. So really what we should do is check both CMAKE_OSX_ARCHITECTURES and the system arch/OS variables, and make meaningful conclusions.

[voltur01]

Hi Ties, thank you for looking into this and updating the patch! Please see a few comments from my side.

[voltur01]

Thank you for addressing the comments!