aboutsummaryrefslogtreecommitdiff
path: root/pkgs/top-level/stage.nix (follow)
Commit message (Collapse)AuthorAgeFilesLines
* tree-wide: do not use pkgs.extend in nixpkgszimbatm2020-11-301-0/+3
| | | | | | | | | Each invocation of pkgs.extends adds 130MB of allocation to the hydra evaluator. We are already struggling with the amount of memory nixpkgs requires. `pkgs.extend` is a useful escape-hatch, but should be not be used inside of nixpkgs directly.
* Distinguish pkgsStatic from pkgsMusl via stdenv.targetPlatformDmitry Bogatov2020-08-271-0/+1
| | | | | | This change allows derivations to distinguish dynamic musl build and static musl build in cases where upstream build system can't detect it by itself.
* symlinkJoin: fix crossAlyssa Ross2019-10-281-1/+1
|
* treewide: remove redundant quotesvolth2019-08-261-6/+6
|
* Merge pull request #57611 from Ericson2314/stage-braid-not-chainJohn Ericson2019-03-251-16/+43
|\ | | | | top-level: Create `pkgs{Build,Host,Target}{Build,Host,Target}`
| * top-level: Create `pkgs{Build,Host,Target}{Build,Host,Target}`John Ericson2019-03-241-16/+43
| | | | | | | | | | | | | | This is needed to avoid confusing and repeated boilerplate for `fooForTarget`. The vast majority of use-cases can still use `buildPackages or `targetPackages`, which are now defined in terms of these.
* | pkgsMusl, pkgsi686Linux, pkgsStatic: fix infinite recursion with overlaysdanbst2019-03-251-0/+9
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider example: $ nix-instantiate ./nixos -A system --arg configuration ' { boot.isContainer = true; nixpkgs.overlays = [ (self: super: { nix = self.pkgsStatic.nix; }) ]; }' When resolving package through overlays, we figure out that nix == self.pkgsStatic.nix => nix == (import <nixpkgs> { inherit overlays; }).nix => nix == (import <nixpkgs> { overlays = [(self: super: { nix = self.pkgsStatic.nix; })];}).nix and we enter infinite recursion of nixpkgs evaluations. The proper fix should terminate recursion by assigning self fixpoint to inner custom package set. But I get infinite recursion somehow, so I use `super`. It is less correct modulo deep custom overrides, but behaves correctly for simple cases and doesn't OOM evaluator. Fixes https://github.com/NixOS/nixpkgs/issues/57984
* pkgs/top-level/stage.nix: don't override `overlays` and `config` in `nixpkgsFun`Jan Malakhovski2019-03-081-2/+0
| | | | | `nixpkgsFun` already sets them via `args`. Doing this also introduces unexpected hard to debug errors, see the patch.
* Merge pull request #56237 from LnL7/expose-overlaysDanylo Hlynskyi2019-03-051-1/+1
|\ | | | | pkgs/top-level: expose current overlays in pkgs
| * pkgs/top-level: expose current overlays in pkgsDaiderd Jordan2019-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This enables inspection of the currently used overlays. Useful for usecases where nixpkgs is imported multiple times. eg. different channels self: super: let latest = import <nixpkgs-trunk> { inherit (super) config overlays; }; in { hello-custom-latest = latest.hello-custom; }
* | treewide: use runtimeShell instead of stdenv.shell whenever possibleJörg Thalheim2019-02-261-0/+1
|/ | | | | | | | | Whenever we create scripts that are installed to $out, we must use runtimeShell in order to get the shell that can be executed on the machine we create the package for. This is relevant for cross-compiling. The only use case for stdenv.shell are scripts that are executed as part of the build system. Usages in checkPhase are borderline however to decrease the likelyhood of people copying the wrong examples, I decided to use runtimeShell as well.
* Partially revert 755e824Robert Hensing2019-02-031-1/+4
| | | | | Reinstates the error message that helps migration of forks. Same should be done for super *if* it is to be removed.
* all-packages: Just refer to `self`, not `super`, or `res`John Ericson2019-02-021-4/+1
| | | | | This ends a years-long process to removoe pointless fixed points in this file!
* top-level/stage.nix: add static overlayMatthew Bauer2018-12-041-0/+16
| | | | | | | | | Adds the static overlay that can be used to build Nixpkgs statically. Can be used like: nix build pkgsStatic.hello Not all packages build, as some rely on dynamic linking.
* all-packages.nix: Alias self to res, deprecating selfRobert Hensing2018-12-021-1/+1
| | | | | | | | | | | | | For historical reasons, self was ill-named. This removes its usages from all-packages.nix and provides a deprecation message for those who use a patched Nixpkgs. Some packages seem to depend on the peculiarities of res, as can be seen by making res into an alias of pkgs (normally "self"). The super variable doesn't have all that is needed. Therefore the simple fix is not guaranteed to work and as such, usages of res need to be changed to pkgs or super, case by case.
* Merge remote-tracking branch 'upstream/master' into ↵Robert Hensing2018-11-041-2/+2
|\ | | | | | | nixos-nixpkgs-pkgs-use-overlays
| * stage.nix: throw error on incorrect pkgsi686Linux usageMatthew Bauer2018-11-031-2/+2
| | | | | | | | | | pkgsi686Linux now throws an error with a message as opposed to the previous assertion.
| * Revert "Revert "stage.nix: pkgsi686Linux only works on x86 family""Matthew Bauer2018-11-031-1/+1
| | | | | | | | This reverts commit 08b5cffe878bcc7ea230043332db53a0ef8d2758.
| * Revert "stage.nix: pkgsi686Linux only works on x86 family"Matthew Bauer2018-11-031-1/+1
| | | | | | | | | | | | This reverts commit 78ca6d885ffbeba8b2cfe1fe68c3980e74fd4e5d. Broke eval on aarch64
| * stage.nix: pkgsi686Linux only works on x86 familyMatthew Bauer2018-11-021-1/+1
| | | | | | | | | | | | | | | | aarch64 cpus are going to break on pkgsi686Linux packages. See this error: https://hydra.nixos.org/build/82962379/
* | pkgs.appendOverlays: Avoid unnecessary nixpkgs evaluationRobert Hensing2018-10-271-1/+3
|/
* Add Nixpkgs functions for adding overlays ad-hocRobert Hensing2018-10-181-1/+14
| | | | | | This is something that I have found useful in tests. In practice I recommend that people call Nixpkgs once for performance and simplicity. The inline documentation mentions this too.
* stage.nix: fix cross compiling with pkgsMuslMatthew Bauer2018-10-151-3/+8
| | | | Fixes #48265
* top-level: `system` should still come from the host platformJohn Ericson2018-09-231-1/+1
| | | | | | | 2a6e4ae49a891adc7c0562fda08b17d60beb1b4f and e51f736076548459f36a1250de4bf6867f880b66 reverted a bit too much, and I initially missed this when reviewing. The release notes already still mention this change, too.
* Revert "top-level: Deprecate top-level `{build,host,target}Platform`"Sarah Brofeldt2018-09-111-11/+5
| | | | This reverts commit e51f736076548459f36a1250de4bf6867f880b66.
* top-level, stdenv: Make `system` and `stdenv.system` describe the hostPlatform.John Ericson2018-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | Intuitively, one cares mainly about the host platform: Platforms differ in meaningful ways but compilation is morally a pure process and probably doesn't care, or those difference are already abstracted away. @Dezgeg also empirically confirmed that > 95% of checks are indeed of the host platform. Yet these attributes in the old cross infrastructure were defined to be the build platform, for expediency. And this was never before changed. (For native builds build and host coincide, so it isn't clear what the intention was.) Fixing this doesn't affect native builds, since again they coincide. It also doesn't affect cross builds of anything in Nixpkgs, as these are no longer used. It could affect external cross builds, but I deem that unlikely as anyone thinking about cross would use more explicit attributes for clarity, all the more so because the rarity of inspecting the build platform.
* top-level: Deprecate top-level `{build,host,target}Platform`John Ericson2018-09-051-5/+11
| | | | | | | | | I don't know when we can/should remove them, but this at least gets people to stop using them. The preferred alternatives also date back to 17.09 so writing forward-compatable code without extra conditions is easy. Beginning with these as they are the least controversial.
* treewide: Purge `stdenv.platform` and top-level `platform`John Ericson2018-08-201-4/+1
| | | | Progress towards #27069
* config.skipAliases -> config.allowAliasesvolth2018-07-171-2/+1
|
* stage: add Linux checksMatthew Bauer2018-07-051-3/+3
| | | | | This prevent us evaluation on macOS systems where pkgsMusl & pkgsi686Linux is unsupported.
* stage: Make `pkgsMusl` and `pkgsi686linux` respect the original localSystem moreJohn Ericson2018-07-051-21/+19
| | | | | | | | | | For example: nix-repl> pkgsi686Linux.pkgsMusl.hostPlatform.config "i686-unknown-linux-musl" nix-repl> pkgsMusl.pkgsi686Linux.hostPlatform.config "i686-unknown-linux-musl"
* treewide: remove forceSystemMatthew Bauer2018-07-051-25/+19
|
* treewide: remove callPackage_i686Matthew Bauer2018-07-051-5/+0
| | | | This has been replaced with pkgsi686Linux.callPackage
* stage: refactor extraPkgsMatthew Bauer2018-07-051-21/+52
| | | | | | | | | | | | | | | | | I have renamed the overlay to “otherPackageSets” because I think that is more descriptive. pkgsLocal has been removed because there were concerns that it would be confusing. None of the other names seemed very useful so I think it is best to avoid it altogether. pkgsCross is still included, hopefully, that will not have as much confusion. pkgsMusl is now available for building Musl packages. It will give you packages bulit with the Musl libc. Also added more documentation. /cc @dezgeg @Ericson2314 @dtzWill
* stage: remove nixpkgsFunMatthew Bauer2018-07-021-5/+3
| | | | also inherit forceSystem for some GNU Hurd stuff
* stage: move old stuff to stage.nixMatthew Bauer2018-07-021-0/+15
|
* top-level: add extraPkgs to stage.nixMatthew Bauer2018-07-021-6/+12
|
* top-level: move cross pkgs to overlayMatthew Bauer2018-07-021-0/+7
|
* aliases: fix using the wrong self refsWill Fancher2018-06-121-1/+1
|
* aliases: add skip aliases configMatthew Bauer2018-05-011-1/+2
| | | | | | You can turn on this config option if you want to find references to aliases in Nixpkgs. Ideally these can be removed from Nixpkgs and eventually we can remove the alias altogether.
* top-level: Duplicate overlaying unless stdenvOverrides comes lastTyson Whitehead2018-01-311-3/+5
| | | | | | | | | | The stdenvOverrides overlay is used to bring packages forward during bootstrapping via stdenv.overrides. These packages have already had the overlays applied to them in the previous boostrapping stage. If stdenvOverrides is not last in the overlays stack, all remaining overlays will windup being applied again to these packages. closes #34086
* Rename `__targetPackages` to `targetPackages`John Ericson2017-11-051-3/+3
|
* top-level: {build,host,target}Platform are defined in the stdenv insteadJohn Ericson2017-07-071-33/+8
| | | | See #27069 for a discussion of this
* top-level: stdenv.cross vanquishedhsloan2017-06-281-2/+0
|
* top-level: `stdenv.cross` is now only defined with host != buildJohn Ericson2017-04-241-2/+2
| | | | | | | | | In practice, this is a strictly stronger condition than target != build as we never have build = target != host. Really, the attribute should be removed altogether, but for now we make it work for plain libraries, which do not care about the target platform. In the few cases where the compilers use this and actually care about the target platform, I'll manually change them to use `targetPlatform` instead.
* top-level: Introduce targetPackages and a "double link fold"John Ericson2017-04-231-0/+10
| | | | | | | | | Each bootstrapping stage ought to just depend on the previous stage, but poorly-written compilers break this elegence. This provides an easy-enough way to depend on the next stage: targetPackages. PLEASE DO NOT USE IT UNLESS YOU MUST! I'm hoping someday in a pleasant future I can revert this commit :)
* stage.nix: Better explain why `buildPackages` as `null` is valid argJohn Ericson2017-04-231-1/+2
|
* top-level: Only splice as needed for performanceJohn Ericson2017-01-241-3/+5
|
* top-level: `crossSystem` is no longer exposed to packages. Use `*Platform`.John Ericson2017-01-241-1/+0
|
* top-level: Lay the groundwork for `{build,host,target}Platform`John Ericson2017-01-241-18/+64
| | | | | | | | | | | | The long term goal is a big replace: { inherit system platform; } => buildPlatform crossSystem => hostPlatform stdenv.cross => targetPlatform And additionally making sure each is defined even when not cross compiling. This commit refactors the bootstrapping code along that vision, but leaves the old identifiers with their null semantics in place so packages can be modernized incrementally.