| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| | |
Build arbitrary Julia package environments in Nixpkgs
|
| | | |
|
| |/
|
| |
Extended genericBuild description
|
| |\
| |
| | |
nixos/doc: Add chapter “necessary system state”
|
| | |
| |
| |
| | |
and add the generating script to `maintainers/scripts/doc`
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Without this, it's impossible to override the lockFile as the default
overrideAttrs is applied after the composition in buildNimPackage has
read the lock file and generated the nim flags from it.
|
| | |\ \
| | |/
| |/| |
doc: Rename to Nixpkgs reference manual and restate purpose
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For the time being, we're moving towards https://nix.dev/ containing
all tutorials and guides. The Nixpkgs manual is reinforced to be a
_reference_ manual. While it's not just reference for now, that's what
the docs team is working towards.
This commits rewrites the Nixpkgs manual introduction to reflect that
and point to some more useful links. The contribution docs are updated
similarly so it's not missed.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
| |\| | |
|
| | | | |
|
| |\| | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GitHub supported special markdown syntax for emphasising blocks for some
time. This was however a beta feature, and still is, so it's subject to
changes.
Recently such a change happened: The syntax is different now.
See https://github.com/orgs/community/discussions/16925 for more
information
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We keep running into situations where we can't get the right
combination of rustc flags through build systems into rustc.
RUSTFLAGS is the only variable supported across build systems, but if
RUSTFLAGS is set, Cargo will ignore all other ways of specifying rustc
flags, including the target-specific ones, which we need to make
dynamic musl builds work. (This is why pkgsCross.musl64.crosvm is
currently broken — it works if you unset separateDebugInfo, which
causes RUSTFLAGS not to be set.)
So, we need to do the same thing we do for C and C++ compilers, and
add a compiler wrapper so we can inject the flags we need, regardless
of the build system.
Currently the wrapper only supports a single mechanism for injecting
flags — the NIX_RUSTFLAGS environment variable. As time goes on,
we'll probably want to add additional features, like target-specific
environment variables.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes the working directory for the suggested flake, as originally
suggested by @MaxDaten in:
https://github.com/NixOS/nixpkgs/issues/229542#issuecomment-1674886874
… and then amended by @Enzime in:
https://github.com/NixOS/nixpkgs/pull/248554#issuecomment-1676825733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Nixpkgs documentation on the linux kernel builders focused on
using and extending kernels that were already packaged, but never
mentioned that it's possible to also build a kernel almost "from
scratch".
The NixOS documentation went a bit deeper on manual linux kernel
configs, but that information wasn't particularly NixOS-specific.
This commit consolidates the information related to building the
kernel on Nixpkgs's documentation, while keeping any additional
NixOS-specific information on NixOS's documentation.
An additional README.md was created for contributor-facing
documentation.
|
| |\
| |
| | |
doc: Add lib.meta to the library functions ToC
|
| | |
| |
| |
| |
| |
| | |
This seems like a pretty easy-to-fix oversight, and it documents the
getExe function, which I never knew about until one day I saw a PR
using it. Let's include it in the manual.
|
| | |
| |
| |
| |
| | |
In x-d-p 1.17, when no configs are given, you apps will likely not
able to find a backend. Let users aware of the changes.
|
| | | |
|
| |\ \
| | |
| | | |
doc/stdenv: update manual phases execution instructions
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Update instructions for manual build phases execution via `nix-shell` to
cover all phases. There is no easy way of getting those commands, so it
makes a sense to have them all properly documented.
|
| |/ /
| |
| |
| |
| |
| | |
Previously the introductory section and the function listings were in
different places. But now nixdoc supports having them together
with https://github.com/nix-community/nixdoc/pull/70!
|
| |\ \
| | |
| | | |
buildDotnetModule small improvements
|
| | | |
| | |
| | |
| | | |
first time
|
| |\ \ \ |
|
| | | | | |
|
| |\| | | |
|
| | |\ \ \ |
|
| | | | | | |
|
| |\| | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
was missed when qt4 was removed
|
| |\| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
- pkgs/development/libraries/gdcm/default.nix
|
| | | | | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
doc: commit header convention for documentation changes
|
| | | | | | | |
|
| |\| | | | | |
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
docs/javascript/introduction: fix GitHub search link
|
| | | | | | | | |
|
| |\| | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | | |
Co-authored-by: Jörg Thalheim <Mic92@users.noreply.github.com>
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commits adds to the manual a tutorial showing how to
troubleshoot breakage caused by a rustc upgrade in *downstream*
packages.
|
| |\| | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Using the script in maintainers/scripts/update-redirected-urls.sh
|
| |\ \ \ \ \ \ |
|
| | |\| | | | | |
|
| | | |\ \ \ \ \ |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Allows splicing to work correctly
from issue 211340
>> 3: Discourage using package sets like python3.pkgs "directly"
> I think about 8 years ago I introduced this and it has been a clear mistake. Since then this pattern was copied throughout. We should indeed go to pythonPackages and also move the helpers such as buildEnv and withPackages into the package set, like haskell already had before.
- FRidh
|
| |\| | | | | | | |
|