| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Functions like isMinGW() and isGnuLibC() have a good reason to exist: They look
at multiple components of the target. But functions like isWasm(), isDarwin(),
isGnu(), etc only exist to save 4-8 characters. I don't think this is a good
enough reason to keep them, especially given that:
* It's not immediately obvious to a reader whether target.isDarwin() means the
same thing as target.os.tag.isDarwin() precisely because isMinGW() and similar
functions *do* look at multiple components.
* It's not clear where we would draw the line. The logical conclusion before
this commit would be to also wrap Arch.isX86(), Os.Tag.isSolarish(),
Abi.isOpenHarmony(), etc... this obviously quickly gets out of hand.
* It's nice to just have a single correct way of doing something.
|
|
|
|
This is an RLS footgun.
Resolves: #21834
|
|
This is necessary since isGnuLibC() is true for hurd, so we need to be able to
represent a glibc version for it.
Also add an Os.TaggedVersionRange.gnuLibCVersion() convenience function.
|
|
|
|
|
|
|
|
|
|
closes #21668
Co-authored-by: Alex Rønne Petersen <alex@alexrp.com>
|
|
Abi.android on its own is not enough to know whether soft float or hard float
should be used. In the C world, androideabi is typically used for the soft float
case, so let's go with that.
Note that Android doesn't have a hard float ABI, so no androideabihf.
Closes #21488.
|
|
The compiler actually doesn't need any functional changes for this: Sema
does reification based on the tag indices of `std.builtin.Type` already!
So, no zig1.wasm update is necessary.
This change is necessary to disallow name clashes between fields and
decls on a type, which is a prerequisite of #9938.
|
|
The `zigTriple()` implementation simply returns `gnu` when a glibc version is provided but a more specific ABI isn't.
|
|
This is a partial revert of 105db13536b4dc2affe130cb8d2eee6c97c89bcd.
As we learned from Void Linux packaging, these options are not actually
helpful since the distribution package manager may very well want to
cross-compile the packages that it is building.
So, let's not overcomplicate things. There are already the standard
options: -Dtarget, -Dcpu, and -Ddynamic-linker.
These options are generally provided when the project generates machine
code artifacts, however, there may be a project that does no such thing,
in which case it makes sense for these options to be missing. The Zig
Build System is a general-purpose build system, after all.
|
|
|
|
On macos, allow targets supported by the SDK. This then spawns `xcrun`
and correct paths are emitted for:
- x86_64-macos
- x86_64-ios
- x86_64-tvos
- x86_64-watchos
- x86_64-ios-macbi
- aarch64-macos
- aarch64-ios
- aarch64-tvos
- aarch64-watchos
- aarch64-ios-macbi
On platforms with android NDK, allow android targets. Example usage:
```
CC=/NDK/.../bin/aarch64-linux-android34-clang zig libc -target aarch64-linux-android
```
|
|
This value is very likely incorrect. When glibc_version is provided but
no explicit ABI is provided, use the string "gnu" instead.
|
|
somebody left a landmine here without even a comment to warn about it
|
|
These functions have been doomed for a long time. Finally I figured out
what the proper relationship between this API and std.Target is.
|
|
|
|
|
