| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
doc: fix dockerTools nix-prefetch-docker example
|
|
|
|
|
|
|
|
* document differences to built-in fetchers
Co-authored-by: Alexander Groleau <source@proof.construction>
|
|
|
|
|
|
|
|
texlive: overrideTeXConfig/withPackages
|
|
|
|
|
|
|
|
* luarocks-packages-updater: init
Goal is to make it possible to maintain out-of-tree luarocks packages
without needing to clone nixpkgs.
maintainers/scripts/update-luarocks-packages gets renamed to
pkgs/development/lua-modules/updater/updater.py
Once merged you can run for instance
nix run nixpkgs#luarocks-packages-updater -- -i contrib/luarocks-packages.csv -o contrib/generated-packages.nix
I also set the parallelism (--proc) to 1 by default else luarocks fails
because of https://github.com/luarocks/luarocks/issues/1540
* Update maintainers/scripts/pluginupdate.py
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
---------
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
|
|
|
|
|
|
|
|
|
|
Emscripten docs: reword and remove mention of `nix-env`
|
|
|
|
lib.fakeSha256 results in `error: hash <fake_hash> does not include a
type, nor is the type otherwise known from context`.
|
|
Avoid Two Sets of systemd Binaries in System Closure
|
|
Generate and refine documentation for `lib.customisation`
|
|
|
|
(#262137)
* doc/stdenv: rewrite manual build procedure to be closer to an auto-build
This is based on
<https://jade.fyi/blog/building-nix-derivations-manually/> plus some
more original research.
The previous version of this section did not work for your choice of
simple Haskell package, e.g. haskellPackages.hscolour, due to things
like `compileBuildDriverPhase` and other custom phases that it
does not address at all.
It seems more correct to use genericBuild in development to harmonize it
with what is actually done.
I feel a little bit like I am committing a sin by suggesting using the
experimental CLI in the manual (afaict I am the first to do this), but I
have given the old version of the command, and there are justifiable
reasons to do it:
* The noted limitations with env-vars are fixed. The one with the
non-empty temp directory was one I ran into myself and oh boy was that
not fun to debug.
* Additionally the outputs are set *before* sourcing `setup.sh`: there
is an issue with nix-shell where the original version of `$out` winds
up in `NIX_LDFLAGS` due to _addRpathPrefix, which means that resulting
executables may not run properly.
It is sad that `nix develop` propagates a wrong value of `SHELL` to
builders, though. It is equally sad that `nix-shell` is essentially
abandoned upstream, with undocumented and not insignificant differences
from `nix develop`.
For the exact script differences:
https://github.com/NixOS/nix/blob/17e6b85d05b3d32df244b1d4e89aa41fd8bdcae8/src/nix-build/nix-build.cc#L516-L551
https://github.com/NixOS/nix/blob/db026103b18fb8b5a719594502edd0f89eb9c268/src/nix/get-env.sh
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
Projects building with meson are currently installTargets. Map these
to install tags, which are roughly equivalent. This allows projects to
selectively install components.
|
|
|
|
buildFlutterApplication: Wrap buildDartApplication
|
|
|
|
Fixes: 10f35ff05df1 ("meson.setupHook: prefer meson commands over ninja")
|
|
|
|
buildFlutterApplication
This allows Dart applications to benefit from the package override system, which is useful for things like FFI dependencies.
|
|
|
|
|
|
`darwin.linux-builder`: Make more observable
|
|
|
|
Adds a basic FOD Fetcher for Bittorrent that uses Transmission as a client
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
doc manuals: add reference to nixos-render-docs
|
|
I chose not to do nixos.{config, options} because that would make it
look too much like a configuration object, which it is not.
A configuration object I would define as for example the result of
calling NixOS, an attrset with `_type = "configuration";`.
Recreating a configuration object without evalModules is quite
feasible but not guaranteed to be correct, and not maintainable.
|
|
|
|
|
|
Meson now comes with its own set of commands for building, testing,
installing etc., that by default wrap around Ninja. The reason to
prefer using the Meson commands is that they take additional
options (e.g. setting custom timeouts for tests — my motivation for
this change).
Here, I've modified the Meson setup hook so that Meson's test and
install commands will be used instead of Ninja's when Meson's
configurePhase is used. This restriction is to avoid starting to run
Meson directly when dealing with custom build systems that wrap around
Meson, like QEMU's. We don't use meson's compile command, as it just
runs ninja, and that's handled fine by the existing Ninja setup hook.
Naturally the Meson commands don't support entirely the same set of
options that the Ninja ones did, but I checked through Nixpkgs to find
any packages using Meson that used any options that wouldn't be picked
up by this new system. I only found one, and it was just setting
checkTarget = "test", which is the default value for Ninja and has no
Meson equivalent (because we directly tell Meson to run the tests
rather than going through a generic job system like Ninja).
Link: https://github.com/NixOS/nixpkgs/issues/113829
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
|
|
buildNpmPackage: support makeWrapperArgs
|
|
|
|
|
|
Co-authored-by: Lily Foster <lily@lily.flowers>
|
|
|
|
|
|
|
