Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

llvmPackages: Make targetLlvmLibraries overridable #355001

Conversation

pwaller
Copy link
Contributor

@pwaller pwaller commented Nov 10, 2024

Pull #320261 introduced the possibility to consistently override
dependencies within an llvm package set. This is useful for development
and testing exotic configurations.

Go one step further and enable overriding targetLlvmLibraries.

This makes it possible to write an overlay such as:

overlays = [
  (self: super: {
    llvmPackages = super.llvmPackages.override (prev: {
      targetLlvmLibraries = super.targetPackages.llvmPackages.libraries // {
        compiler-rt = super.targetPackages.llvmPackages.libraries.compiler-rt.override {
          ...
        }
      };
    });
  })
];

... where the overridden compiler-rt will be used in a pkgsLLVM build.

As a straw man, I've done the minimally invasive thing to the code
structure: targetLlvmLibraries is not an explicitly named parameter
for llvmPackages; but it is available in packageSetArgs if passed.
This makes it slightly less discoverable, but this seems like a
reasonable tradeoff considered that modifying this would be a fairly
advanced/esoteric thing to need to do.

In some ways it would be better to have as an explicit parameter with a
default, but the obvious thing won't work because the default needs to
be a non-trivial expression. Potentially we could instead have it as a
defaulted parameter with the value of 'null', and if it's null, then
compute the current thing.

Signed-off-by: Peter Waller [email protected]

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@github-actions github-actions bot added the 6.topic: llvm/clang Issues related to llvmPackages, clangStdenv and related label Nov 10, 2024
Pull NixOS#320261 introduced the possibility to consistently override
dependencies within an llvm package set. This is useful for development
and testing exotic configurations.

Go one step further and enable overriding targetLlvmLibraries.

This makes it possible to write an overlay such as:

```nix
overlays = [
  (self: super: {
    llvmPackages = super.llvmPackages.override (prev: {
      targetLlvmLibraries = super.targetPackages.llvmPackages.libraries // {
        compiler-rt = super.targetPackages.llvmPackages.libraries.compiler-rt.override {
          ...
        }
      };
    });
  })
];
```

... where the overridden compiler-rt will be used in a pkgsLLVM build.

As a straw man, I've done the minimally invasive thing to the code
structure: `targetLlvmLibraries` is not an explicitly named parameter
for llvmPackages; but it is available in `packageSetArgs` if passed.
This makes it slightly less discoverable, but this seems like a
reasonable tradeoff considered that modifying this would be a fairly
advanced/esoteric thing to need to do.

In some ways it would be better to have as an explicit parameter with a
default, but the obvious thing won't work because the default needs to
be a non-trivial expression. Potentially we could instead have it as a
defaulted parameter with the value of 'null', and if it's null, then
compute the current thing.

Signed-off-by: Peter Waller <[email protected]>
@pwaller pwaller force-pushed the llvmPackages-targetLlvmLibraries-override branch from 80ea80c to 51ba14b Compare November 10, 2024 14:31
@ofborg ofborg bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux labels Nov 11, 2024
@rrbutani rrbutani self-requested a review November 11, 2024 05:27
@pwaller pwaller marked this pull request as ready for review November 11, 2024 18:56
@RossComputerGuy RossComputerGuy added the 12.approvals: 1 This PR was reviewed and approved by one reputable person label Nov 14, 2024
@RossComputerGuy RossComputerGuy merged commit 7c18ea3 into NixOS:master Nov 25, 2024
28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: llvm/clang Issues related to llvmPackages, clangStdenv and related 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux 12.approvals: 1 This PR was reviewed and approved by one reputable person
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants