Merge pull request #8315 from fricklerhandwerk/doc-system

add information on the system type string
This commit is contained in:
Robert Hensing 2023-07-19 12:07:23 +02:00 committed by GitHub
commit eca07b2a47
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 89 additions and 43 deletions

View file

@ -5,7 +5,14 @@ AC_CONFIG_AUX_DIR(config)
AC_PROG_SED AC_PROG_SED
# Construct a Nix system name (like "i686-linux"). # Construct a Nix system name (like "i686-linux"):
# https://www.gnu.org/software/autoconf/manual/html_node/Canonicalizing.html#index-AC_005fCANONICAL_005fHOST-1
# The inital value is produced by the `config/config.guess` script:
# upstream: https://git.savannah.gnu.org/cgit/config.git/tree/config.guess
# It has the following form, which is not documented anywhere:
# <cpu>-<vendor>-<os>[<version>][-<abi>]
# If `./configure` is passed any of the `--host`, `--build`, `--target` options, the value comes from `config/config.sub` instead:
# upstream: https://git.savannah.gnu.org/cgit/config.git/tree/config.sub
AC_CANONICAL_HOST AC_CANONICAL_HOST
AC_MSG_CHECKING([for the canonical Nix system name]) AC_MSG_CHECKING([for the canonical Nix system name])

View file

@ -110,41 +110,72 @@ You can also build Nix for one of the [supported platforms](#platforms).
## Platforms ## Platforms
As specified in [`flake.nix`], Nix can be built for various platforms: Nix can be built for various platforms, as specified in [`flake.nix`]:
- `aarch64-linux`
- `i686-linux`
- `x86_64-darwin`
- `x86_64-linux`
[`flake.nix`]: https://github.com/nixos/nix/blob/master/flake.nix [`flake.nix`]: https://github.com/nixos/nix/blob/master/flake.nix
- `x86_64-linux`
- `x86_64-darwin`
- `i686-linux`
- `aarch64-linux`
- `aarch64-darwin`
- `armv6l-linux`
- `armv7l-linux`
In order to build Nix for a different platform than the one you're currently In order to build Nix for a different platform than the one you're currently
on, you need to have some way for your system Nix to build code for that on, you need a way for your current Nix installation to build code for that
platform. Common solutions include [remote builders] and [binfmt emulation] platform. Common solutions include [remote builders] and [binary format emulation]
(only supported on NixOS). (only supported on NixOS).
[remote builders]: ../advanced-topics/distributed-builds.md [remote builders]: ../advanced-topics/distributed-builds.md
[binfmt emulation]: https://nixos.org/manual/nixos/stable/options.html#opt-boot.binfmt.emulatedSystems [binfmt emulation]: https://nixos.org/manual/nixos/stable/options.html#opt-boot.binfmt.emulatedSystems
These solutions let Nix perform builds as if you're on the native platform, so Given such a setup, executing the build only requires selecting the respective attribute.
executing the build is as simple as For example, to compile for `aarch64-linux`:
```console
$ nix build .#packages.aarch64-linux.default
```
for flake-enabled Nix, or
```console ```console
$ nix-build --attr packages.aarch64-linux.default $ nix-build --attr packages.aarch64-linux.default
``` ```
for classic Nix. or for Nix with the [`flakes`] and [`nix-command`] experimental features enabled:
You can use any of the other supported platforms in place of `aarch64-linux`. ```console
$ nix build .#packages.aarch64-linux.default
```
Cross-compiled builds are available for ARMv6 and ARMv7, and Nix on unsupported platforms can be bootstrapped by adding more `crossSystems` in `flake.nix`. Cross-compiled builds are available for ARMv6 (`armv6l-linux`) and ARMv7 (`armv7l-linux`).
Add more [system types](#system-type) to `crossSystems` in `flake.nix` to bootstrap Nix on unsupported platforms.
## System type
Nix uses a string with he following format to identify the *system type* or *platform* it runs on:
```
<cpu>-<os>[-<abi>]
```
It is set when Nix is compiled for the given system, and based on the output of [`config.guess`](https://github.com/nixos/nix/blob/master/config/config.guess) ([upstream](https://git.savannah.gnu.org/cgit/config.git/tree/config.guess)):
```
<cpu>-<vendor>-<os>[<version>][-<abi>]
```
When Nix is built such that `./configure` is passed any of the `--host`, `--build`, `--target` options, the value is based on the output of [`config.sub`](https://github.com/nixos/nix/blob/master/config/config.sub) ([upstream](https://git.savannah.gnu.org/cgit/config.git/tree/config.sub)):
```
<cpu>-<vendor>[-<kernel>]-<os>
```
For historic reasons and backward-compatibility, some CPU and OS identifiers are translated from the GNU Autotools naming convention in [`configure.ac`](https://github.com/nixos/nix/blob/master/config/config.sub) as follows:
| `config.guess` | Nix |
|----------------------------|---------------------|
| `amd64` | `x86_64` |
| `i*86` | `i686` |
| `arm6` | `arm6l` |
| `arm7` | `arm7l` |
| `linux-gnu*` | `linux` |
| `linux-musl*` | `linux` |
## Compilation environments ## Compilation environments

View file

@ -193,18 +193,24 @@ public:
Setting<std::string> thisSystem{ Setting<std::string> thisSystem{
this, SYSTEM, "system", this, SYSTEM, "system",
R"( R"(
This option specifies the canonical Nix system name of the current The system type of the current Nix installation.
installation, such as `i686-linux` or `x86_64-darwin`. Nix can only Nix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in [`extra-platforms`](#conf-extra-platforms).
build derivations whose `system` attribute equals the value
specified here. In general, it never makes sense to modify this
value from its default, since you can use it to lie about the
platform you are building on (e.g., perform a Mac OS build on a
Linux machine; the result would obviously be wrong). It only makes
sense if the Nix binaries can run on multiple platforms, e.g.,
universal binaries that run on `x86_64-linux` and `i686-linux`.
It defaults to the canonical Nix system name detected by `configure` The default value is set when Nix itself is compiled for the system it will run on.
at build time. The following system types are widely used, as [Nix is actively supported on these platforms](@docroot@/contributing/hacking.md#platforms):
- `x86_64-linux`
- `x86_64-darwin`
- `i686-linux`
- `aarch64-linux`
- `aarch64-darwin`
- `armv6l-linux`
- `armv7l-linux`
In general, you do not have to modify this setting.
While you can force Nix to run a Darwin-specific `builder` executable on a Linux machine, the result would obviously be wrong.
This value is available in the Nix language as [`builtins.currentSystem`](@docroot@/language/builtin-constants.md#builtins-currentSystem).
)"}; )"};
Setting<time_t> maxSilentTime{ Setting<time_t> maxSilentTime{
@ -670,18 +676,20 @@ public:
getDefaultExtraPlatforms(), getDefaultExtraPlatforms(),
"extra-platforms", "extra-platforms",
R"( R"(
Platforms other than the native one which this machine is capable of System types of executables that can be run on this machine.
building for. This can be useful for supporting additional
architectures on compatible machines: i686-linux can be built on Nix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in the [`system` option](#conf-system).
x86\_64-linux machines (and the default for this setting reflects
this); armv7 is backwards-compatible with armv6 and armv5tel; some Setting this can be useful to build derivations locally on compatible machines:
aarch64 machines can also natively run 32-bit ARM code; and - `i686-linux` executables can be run on `x86_64-linux` machines (set by default)
qemu-user may be used to support non-native platforms (though this - `x86_64-darwin` executables can be run on macOS `aarch64-darwin` with Rosetta 2 (set by default where applicable)
may be slow and buggy). Most values for this are not enabled by - `armv6` and `armv5tel` executables can be run on `armv7`
default because build systems will often misdetect the target - some `aarch64` machines can also natively run 32-bit ARM code
platform and generate incompatible code, so you may wish to - `qemu-user` may be used to support non-native platforms (though this
cross-check the results of using this option against proper may be slow and buggy)
natively-built versions of your derivations.
Build systems will usually detect the target platform to be the current physical system and therefore produce machine code incompatible with what may be intended in the derivation.
You should design your derivation's `builder` accordingly and cross-check the results when using this option against natively-built versions of your derivation.
)", {}, false}; )", {}, false};
Setting<StringSet> systemFeatures{ Setting<StringSet> systemFeatures{