Allow setting `sourceRoot` and `setSourceRoot` in the arguments to
`haskellPackages.mkDerivation`. These arguments are passed directly to
`stdenv.mkDerivation`.
It may be worth reading over `pkgs/stdenv/generic/setup.sh` and checking
if there's other unsupported variables which may be useful. It may also
be worth adding an argument like `extraAttrs` to be passed to
`stdenv.mkDerivation` directly, as an escape hatch.
this removes the hard-coded listing from the Haskell examples, which can later be replaced by
a dynamic one as for the Python interpreters
* fix broken reference
* clarify why using `nix-env --query` makes sense
Co-authored-by: wamirez <wamirez@protonmail.com>
This makes `justStaticExecutables` error if the produced store path
contains references to GHC. This is almost always erroneous and due to
the generated `Paths_*` module being imported. This helps prevent
`justStaticExecutables` from producing binaries with closure sizes in
the gigabytes.
See: https://github.com/NixOS/nixpkgs/issues/164630
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
Fixes#256769
Repro + test of fix here: https://gitlab.com/ramirez7/bug-repros/-/merge_requests/1
Adds a `srcModifier` argument to `callCabal2nixWithOptions` to allow
customizing the source files used to generate the cabal file (e.g. to
support `hpack`/`package.yaml`).
`lib.recursiveUpdate` indiscriminately recurses into all attribute sets,
also into derivations. This means that it is possible that evaluating a
derivation in the final haskell package set can cause something in
`prev.haskell` to be forced by `recursiveUpdate`, potentially causing an
evaluation error that should not happen.
It can be fixed using a well-crafted predicate for
`lib.recursiveUpdateUntil`, but most robust is just explicitly writing
out the desired merging manually.
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)
This is actually relatively complicated to achieve, since it involves
overriding GHC on e.g. aarch64-darwin, so the FAQ entry seems warranted.
It's also a good exercise to me, since it demonstrates some problems
with the overriding infrastructure, i.e. that it has a tendency to
inherit the pkgs fixpoint from prev. An example of this problem is
https://github.com/NixOS/nixpkgs/issues/235960, but it has different
manifestations as well. Awareness of this will also help writing the
other sections on overriding.
How complicated it is, seems to be further incentive to go ahead with
https://github.com/NixOS/nixpkgs/pull/239548 as well.
without stable ids on headings we cannot generate stable links to these
headings. nrd complains about this, but the current docbook workflow
does not.
a few generated ids remain, mostly in examples and footnotes. most of
the examples are generated by nixdoc (which has since gained MD export
functions, and the MD export does generate IDs).
According to the Unicode Standard, you should use U+2019 RIGHT SINGLE
QUOTATION MARK for apostrophes [1]. Before this change, some of the text
in this repo would use U+2018 LEFT SINGLE QUOTATION MARKs instead.
[1]: https://www.unicode.org/versions/Unicode15.0.0/ch06.pdf#G12411
These are some suggested changes to the new documentation of Haskell in
the Nixpkgs manual. They cover sections until, but excluding, the
section "Available package versions". I am not an English native
speaker, so please correct me and savage these changes!
Also, please let me know if the suggestions are welcome, then I will
continue with the next chapter.
This restarts a Haskell section in the nixpkgs manual. The content
presented here has been written from scratch, although some parts of it
take inspiration from the existing haskell4nix documentation.
It is by no means complete, the idea is mostly to get the ball rolling
in some way. Upcoming tasks are hinted at in the comments in the
documentation file.
I used the existing anchors generated by Docbook, so the anchor part
should be a no-op. This could be useful depending on the
infrastructure we choose to use, and it is better to be explicit than
rely on Docbook's id generating algorithms.
I got rid of the metadata segments of the Markdown files, because they
are outdated, inaccurate, and could make people less willing to change
them without speaking with the author.
* ghcHEAD: bump to 8.11.20200403
* ghcHead: reduce diff vs. 8.10.1
dontAddExtraLibs was removed by accident (IMO) in ea19a8ed1e
* ghcHEAD: add ability to use system libffi
- enable nixpkgs' libffi
- minimise diffs against 8.10.1
- remove patching
* remove configure warning about --with-curses-includes
configure: WARNING: unrecognized options: --with-curses-includes
Reorganize the chapters into parts and reduce the TOC depth to make the
TOC useful again. The top-level TOC is very brief, but that is fine
because every part will have its own TOC.
Section titles of languages/frameworks are also simplified to just
the name of the language/framework.
