The new plan to support hobby operating systems is #3784.
And what kind of name is "Zen" anyway? There's already a
[Zen programming language](http://zenlang.sourceforge.net/)
and that's just confusing.
Clang does not support -march=native for all targets.
Arguably it should always work, but in reality it gives:
error: the clang compiler does not support '-march=native'
If we move CPU detection logic into Zig itelf, we will not need this,
instead we will always pass target features and CPU configuration explicitly.
For now, we simply avoid passing the flag when it is known to not be
supported.
This reverts commit ec7d7a5b14540ea3b2bab9f11318630338467965, reversing
changes made to 81c441f8855d4c58f0b2ff86d3d007cf0bf395d3.
It looks like this broke colors in Windows Command Prompt (#3147)
and this method of detecting native C ABI isn't working well (#3121).
Zig provides a libc for the GNU C ABI on Windows, and cannot (at least
yet) provide one for the MSVC C ABI. However when not linking libc,
zig has no problem targeting MSVC as the C ABI. And this should be the
default.
Related: #2911
* fixed --verbose-cc printing an extra "zig" before the rest of
the command line
* windows-gnu targets use libfoo.a, foo.o extensions to match mingw
conventions.
windows.h has files such as pshpack1.h which do #pragma packing,
triggering a clang warning. So for this target, this warning is
disabled.
this commit also improves the error message printed when no libc can be
used, printing the "zig triple" rather than the "llvm triple".
Fixes glibc_version being set to garbage. I've made this mistake
before so this is an attempt to prevent future bugs. Zig doesn't
have zero-initialization, so are we being a hypocrite by using this
C feature? No, because C doesn't have the feature that forces you to
initialize all fields. That would have prevented this bug every single
time.
