lib.systems.examples: deprecate in preparation for removal #250073
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
6.topic: nixos
ghost
mentioned this pull request
12 tasks
ghost
requested a review
from
github-actions
bot
added
6.topic: python
6.topic: qt/kde
6.topic: kernel
added 2 commits
August 19, 2023 03:15
For almost a decade nixpkgs has parsed `*-*-{cygwin,msvc}` as being
ABIs for a common kernel (windows), rather than as kernels. It
isn't really reasonable to change nixpkgs' handling at this point,
so this commit replicates the special-case hack when unparsing, in
order to ensure that `(unparse . parse)==id`.
tripleFromSkeleton contains the same logic found in tripleFromSystem, but is capable of operating on unvalidated attrsets-of-strings.
added 25 commits
August 19, 2023 03:15
gnu-config does not recognize `none` as a vendor -- that string describes a *kernel*
Unfortunately gnu-config triples are, in some rare cases, sensitive to whether the vendor was specified as `unknown` or was omitted. In other words, there are situations where these are not handled exactly the same way: - `mips-linux-gnu` - `mips-unknown-linux-gnu` This commit introduces `lib.systems.tripleFromSystemLossy`, which returns `"mips-unknown-linux-gnu"` for both of the platforms above. This is almost always what you want to use.
Since 4aa1ffa we have been shipping reverse-engineered out-of-tree forks of gcc and binutils for the Broadcom VC4. Upstream for those forks chose the nonstandard `vc4-elf` triple to identify their system. GNU config rejects this triple (and all `vc4-*` triples). This commit deals with the fallout from that. Mainly this commit ensures that we are consistent in using `vc4-elf` instead of `vc4-none`, and makes sure that parsing->unparsing round-trips properly.
GNU config (correctly) considers Solaris to be a BSD, and therefore appends its version to the kernel name, which should be `solaris2` not `solaris`. This commit updates `lib/systems` to do the same.
Each kernel supports only a subset of the universe of possible ABIs. This commit explicitly lists (opt-in) the allowable abis for each kernel. Attempting to parse a kernel with an abi which is not on the list will fail. This "search space pruning" is essential to getting our gnu-config agreement tests down to a manageable set of test cases. It also lets us reject nonsense triples instead of trying to handle them exactly the same way gnu-config does.
In PR #182807 we decided that big-endian PowerPC64 should default to the new elfv2 ABI. The implementation in that PR did the defaulting by adding two lines in the *triple parser*, which is turning out to be problematic; it means that our parse-then-unparse roundtrip disagrees with gnu-config. This commit therefore reverts just those two lines. If the defaulting logic needs to be moved elsewhere that should be done. https://github.com/NixOS/nixpkgs/pull/182807/files#r1234650738
This is required for agreement with gnu-config.
gnu-config doesn't include this.
This commit fixes the logic for handling missing/unknown vendor fields in triples, and extends it to handle mmix and microblaze CPU-types.
This commit adds lib/tests/triples.nix, which exhaustively tests that our platform triple parse-then-unparse round-trip agrees with gnu-config for all inputs that it accepts (it may -- and does -- reject triples which `gnu-config` accepts).
With this commit, we now parse or reject the following identically to gnu-config: - aarch64-solo5-none (accept) - aarch64-solo5-none-elf (reject) Closes #165836.
This commit adds support for triples with a missing kernel, rather than kernel="none". It also adds a parser case for triples which have a vendor and abi, but no kernel. This allows to parse "*-unknown-elf" triples. Closes #230160.
`kernel=windows` is sort of a nixpkgs-ism; we parse triples differently than gnu-config but then undo the difference when unparsing in order to match its behavior. However when platform objects are constructed internally they don't have access to this hackery, so we need to permit direct construction of gnu-config-invalid platform objects in order to cover this case.
This commit adds `pkgs.pkgsOn`, which serves the same purpose as `pkgs.pkgsCross`, except that *it does not rely on a pre-approved/blessed list of acceptable platforms* (i.e. `lib.systems.examples`). This is intended to replace `pkgs.pkgsCross` so that `lib.systems.examples` can be deprecated.
This reverts commit 71e9c903c1bccdb9c94f8e0e28370571815b8950.
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Migrates
pkgsCrosstopkgsOn, which does not require a "blessed" list of approved platforms (lib.systems.examples).pkgsCross.aarch64-multiplatform.bashpkgsOn.aarch64.unknown.linux.gnu.bashTasks
pkgsOnpkgsCrosstopkgsOnlib.warntopkgsCrosslib.systems.examplesbuiltins.attrNames lib.systems.examplesto pre-populate a cache... migrating this is tricky for me to test correctly.lib.warntolib.systems.examplesIncludes:
Note: this doesn't try fix the "cognitive ugliness" of
pkgsCross/pkgsOnbeing "inside" ofpkgs. That's an orthogonal problem, which is worth solving but also going to be a harder sell to the community because.pkgsSomething.blahis so syntactically convenient. I don't want that debate to obstruct the removal oflib.systems.examples.