@henderkes

I suddenly had a terrible idea (for now): for Linux builds, how about splitting SPC_LIBC into SPC_TOOLCHAIN and SPC_TARGET?

• SPC_TOOLCHAIN ​​uses zig by default after zig is implemented, and others include alpine-native and musl. Create a tool class: SPCToolchain. For windows and macOS: msbuild, clang.
• SPC_TARGET includes musl-static, musl, and glibc. We can choose according to the situation in the next major version. Tool class: SPCTarget. For windows and macOS: darwin-{some-minimal-version-num}, windows-7|8|10|11

So we have a table:

You may not want alpine-native this name, but it does exist - based on alpine-docker or Alpine Linux and can only be used in these env.
And for musl (formerly musl-toolchain we built), it should be the default solution before our breaking changes.

The advantage is that we can avoid judging the CC variable on this basis, and we can expand the SPC_TOOLCHAIN and libc targets on this basis (assuming it is possible in the future). We can also add different names for Mac and Win to avoid judging whether the current system is Linux at first in general-use code.

And if we finished this, we could remove or add a toolchain support more easily, just check all the toolchain constant reference.

The disadvantage is that it does not fundamentally solve the problem of different tool chains, introduces additional variables, and causes destructive updates.

If we continue to add more duplicate CC checks on top of this, it will make it very difficult to temporarily change these values. But I don't think it is necessary, except that few of us will frequently debug SPC internals and different builds.