I've had better luck creating statically-linked binaries that work than
dynamically-linked ones, so this is needed quite practically.
(cherry picked from commit 676df1cf2d)
Following [Best Practices](https://nix.dev/guides/best-practices#with-scopes),
`with` is a problematic language construction and should be avoided.
Usually it is employed like a "factorization": `[ X.A X.B X.C X.D ]` is written
`with X; [ A B C D ]`.
However, as shown in the link above, the syntatical rules of `with` are not so
intuitive, and this "distributive rule" is very selective, in the sense that
`with X; [ A B C D ]` is not equivalent to `[ X.A X.B X.C X.D ]`.
However, this factorization is still useful to "squeeze" some code, especially
in lists like `meta.maintainers`.
On the other hand, it becomes less justifiable in bigger scopes. This is
especially true in cases like `with lib;` in the top of expression and in sets
like `meta = with lib; { . . . }`.
That being said, this patch removes most of example code in the current
documentation.
The exceptions are, for now
- doc/functions/generators.section.md
- doc/languages-frameworks/coq.section.md
because, well, they are way more complicated, and I couldn't parse them
mentally - yet another reason why `with` should be avoided!
https://www.pcre.org/
The `pcre` library is "now at end of life, and is no longer being
maintained," according to the upstream maintainers. Accordingly, we
should replace uses of `pcre` with its actively maintained successor,
`pcre2`, wherever possible .
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.
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
* 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:
17e6b85d05/src/nix-build/nix-build.cc (L516-L551)db026103b1/src/nix/get-env.sh
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
* nixpkgs manual: add an alternative example in stdenv-separateDebugInfo
This change gets rid of the indirect reference to `nix-env -i` usage
and shows how to achieve the same goal with a shell expression.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
The text was originally added [0] following an apparently incomplete
research on how everything plays together. In fact, Nix propagates
`outputs` to the corresponding nested derivations, and there is some
messy behavior in Nixpkgs that only seems to propagate
`meta.outputsToInstall` in `buildEnv`[1].
This change moves the hints on how to use NixOS specifics to NixOS
module documentation (which is hopefully easier to find through
search.nixos.org), describes the default behavior in Nixpkgs (updating
a the link to the source), and removes the confusing mention of
`nix-env`.
the last of them should not be there to begin with. we don't want
beginners to use `nix-env`, as this is known to run them into trouble
eventually.
[0]: https://github.com/NixOS/nixpkgs/pull/76794
[1]: 1774d07242/pkgs/build-support/buildenv/default.nix (L66)
* Updates meta.chapter.md with a reference link to the usage of the package description field instead of referring to nix-env
---------
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
also updates nixdoc to 2.3.0. the nixdoc update is not a separate commit
because that would leave the manual build broken for one commit,
potentially breaking bisects and rebases.
pandoc recognizes `::: note` admonitions, nixos-render-docs only
recognizes `::: {.note}`. surprisingly pandoc also emits the correct
docbook tags for `[](#xref)`s, so we can use that too.
* doc/stdenv/meta.chapter.md: document meta.badPlatforms
We don't have any documentation for the `meta.badPlatforms` attribute.
This commit adds documentation for it.
