summary refs log tree commit diff
path: root/pkgs/top-level/default.nix
Commit message (Collapse)AuthorAge
* systems: allow passing in string for cross/localSystemMatthew Bauer2019-06-04
| | | | | | This makes things a little bit more convenient. Just pass in like: $ nix-build ’<nixpkgs>’ -A hello --argstr localSystem x86_64-linux --argstr crossSystem aarch64-linux
* pkgs/top-level/stage.nix: don't override `overlays` and `config` in `nixpkgsFun`Jan Malakhovski2019-03-08
| | | | | `nixpkgsFun` already sets them via `args`. Doing this also introduces unexpected hard to debug errors, see the patch.
* pkgs/top-level: check types of `nixpkgs.config`Jan Malakhovski2019-03-08
| | | | | | This patch simply introduces a plain simple NixOS module and passes `nixpkgs.config` through it via `evalModules` (with some temporary hackery to passthru undefined options).
* top-level: fix a typoJan Malakhovski2019-02-03
|
* stdenv: implement crossOverlaysMatthew Bauer2018-12-04
| | | | | | | | crossOverlays only apply to the packages being built, not the build packages. It is useful when you don’t care what is used to build your packages, just what is being built. The idea relies heavily on the cross compiling infrastructure. Using this implies that we need to create a cross stdenv.
* top-level: Move comma for stylistic consistencyJohn Ericson2018-03-20
|
* Add setFunctionArgs lib function.Shea Levy2018-01-31
| | | | | | Among other things, this will allow *2nix tools to output plain data while still being composable with the traditional callPackage/.override interfaces.
* Fix typo in commentBjørn Forsman2017-04-19
|
* Elaborate `localSystem` and `crossSystem` in a consistent mannerJohn Ericson2017-04-17
|
* lib: Collect system/platform related filesJohn Ericson2017-04-17
| | | | Previously, platforms was a random thing in top-level
* top-level: Allow nixpkgs to take localSystem directlyJohn Ericson2017-02-08
| | | | This is instead of both system and platform, which is kind of ugly.
* top-level: Document the `{local,cross}System, contrasting with `*Platform`John Ericson2017-01-24
| | | | | This is an implementation detail of how the bootstrapping chain is chosen, and thus need not be in the manual.
* top-level: Lay the groundwork for `{build,host,target}Platform`John Ericson2017-01-24
| | | | | | | | | | | | 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.
* Add overlays mechanism to Nixpkgs.Nicolas B. Pierron2017-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch add a new argument to Nixpkgs default expression named "overlays". By default, the value of the argument is either taken from the environment variable `NIXPKGS_OVERLAYS`, or from the directory `~/.nixpkgs/overlays/`. If the environment variable does not name a valid directory then this mechanism would fallback on the home directory. If the home directory does not exists it will fallback on an empty list of overlays. The overlays directory should contain the list of extra Nixpkgs stages which would be used to extend the content of Nixpkgs, with additional set of packages. The overlays, i-e directory, files, symbolic links are used in alphabetical order. The simplest overlay which extends Nixpkgs with nothing looks like: ```nix self: super: { } ``` More refined overlays can use `super` as the basis for building new packages, and `self` as a way to query the final result of the fix-point. An example of overlay which extends Nixpkgs with a small set of packages can be found at: https://github.com/nbp/nixpkgs-mozilla/blob/nixpkgs-overlay/moz-overlay.nix To use this file, checkout the repository and add a symbolic link to the `moz-overlay.nix` file in `~/.nixpkgs/overlays` directory.
* top-level: Normalize stdenv bootingJohn Ericson2017-01-13
| | | | | | | | | | | Introduce new abstraction, `stdenv/booter.nix` for composing bootstraping stages, and use it everywhere for consistency. See that file for more doc. Stdenvs besides Linux and Darwin are completely refactored to utilize this. Those two, due to their size and complexity, are minimally edited for easier reviewing. No hashes should be changed.
* top-level: missing parenthesesEric Litak2016-12-20
|
* top-level: avoid another `assert false` while we're at itJohn Ericson2016-12-15
|
* top-level: Allow manually specifying a stdenv, and fix stdenv testsJohn Ericson2016-12-03
| | | | | | | - The darwin test can now force the use of the freshly-booted darwin stdenv - The linux test now passes enough dummy arguments This may make debugging harder, if so, check out #20889
* top-level: Document why `nixpkgsFun` doesn't close over inferred default ↵John Ericson2016-12-01
| | | | arguments
* top-level: Move default-choosing logic to top-level/platforms.nixJohn Ericson2016-12-01
| | | | This mirrors stdenv/default.nix
* top-level: Close over fewer arguments for stdenv stagesJohn Ericson2016-11-30
| | | | | | | | This makes the flow of data easier to understand. There's little downside because the args in question are already inspected by the stdenvs. cross-compiling in particular is simpler because we don't need to worry about overriding the config closed over by `allPackages`.
* top-level: Remove cycles: stdenv calls in top-level but not vice versaJohn Ericson2016-11-30
| | | | | | | | | | | | | | | | | | | | | | | This commit changes the dependencies of stdenv, and clean-up the stdenv story by removing the `defaultStdenv` attribute as well as the `bootStdenv` parameter. Before, the final bootstrapping stage's stdenv was provided by all-packages, which was iterating multiple times over the top-level/default.nix expression, and non-final bootstrapping stages' stdenvs were explicitly specified with the `bootStdenv` parameter. Now, all stages' stdenvs are specified with the `stdenv` parameter. For non-final bootstrapping stages, this is a small change---basically just rename the parameter. For the final stage, top-level/default.nix takes the chosen stdenv and makes the final stage with it. `allPackages` is used to make all bootstrapping stages, final and non-final alike. It's basically the expression of `stage.nix` (along with a few partially-applied default arguments) Note, the make-bootstrap-tools scripts are temporarily broken
* top-level: Split some of `pkgs/top-level/default.nix` to ↵John Ericson2016-11-30
| | | | | | | `pkgs/top-level/stage.nix` This is preparation for the latter just building a single stage, and the former building a package set with the bootstrapped stdenv.
* top-level: `top-level/stdenv.nix` no longer needs `pkg` argumentJohn Ericson2016-11-06
|
* top-level: Make stdenvCross which appears at first glance normal...John Ericson2016-11-06
| | | | ...but actually is weird just like the original
* top-level: Remove redundant arguments from top-level/{all-package,stdenv}.nixJohn Ericson2016-11-02
|
* top-level: Inline topLevelArugments, and make pkg named arg for stdenvJohn Ericson2016-11-02
| | | | [Trying my best to indent properly while avoiding excessive drift]
* top-level: Remove redundant parenthesesJohn Ericson2016-11-02
|
* top-level: Use `nixpkgsFun` to avoid import ../..John Ericson2016-11-02
|
* top-level: Use foldl' to make the list of package functions top to bottomJohn Ericson2016-10-13
|
* top-level: Make `overridePackages` extend rather than replace existing overridesJohn Ericson2016-10-13
|
* runCommand: Use stdenvNoCCEelco Dolstra2016-09-29
| | | | | | This ensures that most "trivial" derivations used to build NixOS configurations no longer depend on GCC. For commands that do invoke gcc, there is runCommandCC.
* Separate fix-point from config importing hacks and other impuritiesJohn Ericson2016-07-14
|
* Make default config an argument default instead of using null checkJohn Ericson2016-07-09
| | | | Thanks @Mathnerd314 for this idea
* Remove gccWith* arguments which are unusedJohn Ericson2016-06-22
|
* top-level: builtins.toPath no longer neededJohn Ericson2016-06-21
|
* Remove unecessary branching on old nix versionszimbatm2016-06-17
| | | | | All these builtins are available since 1.10 or earlier (1.10 being the lib/minver.nix)
* Fix comments typos.Nicolas B. Pierron2016-03-24
|
* Move stdenvOverrides under pkgsWithOverrides.Nicolas B. Pierron2016-03-20
|
* Replace the merge operators by the fix' and extends functions.Nicolas B. Pierron2016-03-20
|
* Under pkgsWithOverrides, replace the last uses of pkgs by the corresponding ↵Nicolas B. Pierron2016-03-20
| | | | argument.
* Change the customOverrides to use the stdenvOverrides instead of the ↵Nicolas B. Pierron2016-03-20
| | | | original package set.
* Move the customOverrides after the stdenvOverrides.Nicolas B. Pierron2016-03-20
| | | | | | | This change is not backward compatible, in the sense that this allow you to override the packages which used to be overriden by the last stage of stdenv. Note, this does not mean that these packages would be used by stdenv.
* Add bootStdenv condition around the overrider.Nicolas B. Pierron2016-03-20
| | | | | | | This condition used to be implicit in the sense that the stdenvOverrides uses pkgs_6, instead of pkgs_7 as its super set, and also that each stage of the compiler is build again the bootstrap packages of the previous stage, thus overriden by the stdenv.override function.
* Add extra argument to better identity with the extend function later.Nicolas B. Pierron2016-03-20
|
* In top-level/default.nix, rename self to allPackages.Nicolas B. Pierron2016-03-20
|
* Internalize the recursion over the set of all packages.Nicolas B. Pierron2016-03-20
|
* Build aliases based on the previous set including all-packages, instead of ↵Nicolas B. Pierron2016-03-20
| | | | only using all-packages.
* Move stdenvAdapaters attribute from all-packages.nix into the stdenvAdapters ↵Nicolas B. Pierron2016-03-20
| | | | of the top-level.
* Split helperFunctions to simplify the identification with the extend function.Nicolas B. Pierron2016-03-20
|
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-06-07 06:32:41 +0000