the gnome2 namespace nebulously refers to an gnome 2, a desktop we never
properly packaged. now it holds a bunch of gtk2 or otherwise unused
packages. its contents were handled in previous commits, and now that it
is empty except for aliases, we drop the namespace entirely. aliases
were added only for the recent additions to the list, as the ones from
before 2024 seem to have little use and are no longer kept in
aliases.nix.
The package set is built entirely from source using the stdenv and Hugs.
This also replaces the recently added microhs package, which was built
from pre-generated compiler output.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
srcOnly applies patches, but the resulting derivation still had the
patches attribute, causing patchPhase to apply them again. Clear
patches after srcOnly to prevent double-application.
Our wrapper for lib.makeOverridable wraps the underlying function which
means the wrapper function doesn't replicate the same set pattern.
We can, however, tell lib.functionArgs about the permissible arguments
by making the function a functor and adding __functionArgs.
- The LLVM backend always needs an LLVM specific assembler, i.e. clang
that ideally matches the version of LLVM actually used for codegen.
- The LLVM backend on Darwin requires some version of clang to be
available. In light of LLVMAS, using a matching version seems to be
best though this does risk messing with clang used for compiling C
in the derivation.
This mess can be avoided by compiling GHC with useLLVM = true which
sets absolute paths in GHC's settings file. Due to closure size
constraints, we can't really do that if NCG is available.
There’s no sensible notion of a Haskell package set’s LLVM, only a
GHC’s LLVM. `haskellPackages.ghc.llvmPackages` is still accessible,
although you probably don’t actually want to use it very often.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
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`).
The original change missed that we used to erroneously provide LLVM on
aarch64-linux, but not on aarch64-darwin which was later fixed
in #246045. Since the change was tested on aarch64-linux prior to this,
tls ended up being broken on both aarch64-linux and aarch64-darwin.
This commit resolves the situation by introducing a helper function to
achieve the effect of passing -fllvm while ensuring LLVM is provided.
Resolves#260013.
ghcWithHoogle was using unoverridden packages pulled from the
buildHaskellPackages package set. This commit fixes that by pulling the
packages from self instead.
ghc and also ghcWithPackages (when taken from a haskell package set) are
a bit weird—in the same way stdenv is: ghc is actually from
buildPackages (pkgsBuildHost) wheras the main package set belongs to
pkgsHostTarget. ghc (and stdenv) is included in the package set due to
its special relation to the set: it is built by that ghc, so constituted
by the compiler in a manner of speaking.
For ghc this works in a straightforward way: It is packaged
independently from the haskell package sets and passed to
make-package-set.nix to create the different sets we expose.
With ghcWithPackages an error crept in, though: Since it needs to
receive the haskellPackages fix point (and thus can't be instantiated
before the package set), it is defined in make-package-set.nix. Here it
was neglected to make sure that it also has the same scope as ghc, i.e.
buildHaskellPackages/buildPackages: Otherwise the shell the wrapper
scripts use to invoke ghc (originally from buildPackages) would be from
pkgsHostTarget—in the cross case, the wrapper scripts would be
executable by neither host nor build platform. We want them to work on
the build platform, though.
Note that this creates a weird mismatch where it is hard to see which of
the alternatives would be more natural: ghcWithPackages and
ghcWithHoogle now use packages from the package set they are a member
of, but have *-ghc and hoogle executables that are executable on the
build platform. This works because ghc originates from buildPackages (as
discussed) and hoogleWithPackages is taken from buildHaskellPackages.
This does imply though that while set.ghcWithHoogle will be executable
on the build platform, set.hoogleWithPackages will be executable on the
host platform—both will use the fix point of set for the package
selector function. This is maybe a confusing asymmetry, but it seems
like a valid use case to cross-compile a hoogle instance. Most
development tools use ghcWithHoogle (or equivalent), so that use case is
covered as well in principle.
Packages built with `haskellPackages.callHackage` won't be rebuilt when
updating `all-cabal-hashes`.
The removed comment was keeping a reference to the `cabal2nix` call,
which itself depends on `all-cabal-hashes`, in order to keep this file
during a garbage collection.
The tradeoff is between:
- The current behavior: a mass rebuild, any change of `all-cabal-hashes`
triggers a rebuild of all the packages built with `callHackage` and
packages which depend on them. This can take hours, and may happen
after a "small" unrelated change (i.e. an user is bumping
`all-cabal-hashes` in order to use a new package from hackage). It
also have global impacts in a project (long rebuild in CI, new entries
in cache, developers need to fetch the new entries, ...). In this
context, `cabal2nix` entries are not garbage collected.
- The new behavior: No mass rebuild, but `cabal2nix` derivations need to
be recomputed after a garbage collection. This is usually fast (a few
seconds by call), linear with the number of calls and should not
happen a lot (i.e. users are not garbage collecting everyday).
See https://github.com/NixOS/nixpkgs/issues/194751 for details.
Deprecate haskell.lib{,.compose}.generateOptparseApplicativeCompletion*
in favor of the newly added
haskell.packages.*.generateOptparseApplicativeCompletions (plural!)
which takes into account whether we are cross-compiling or not. If we
are, generating completions is disabled, since we can't execute software
built for a different platform.
The move is necessary, so we can receive the /same/ stdenv as the
package we are overriding in order to accurately check whether we can
execute produced binaries.
Resolves#174040.
Resolves#49648.
* all-cabal-hahses can be a directory
Motivating problem: we want to use the flake.lock for all-cabal-hashes
as a github repository as our revision pin, and then import that to pass
as all-cabal-hashes. To do that we need it to accept a directory rather
than a tarball.
* all-cabal-hashes: add some comments
This is achieved by passing the entire package set to the respective
wrappers and passing the select function as a second attribute. Together
with the new support for callPackage-ing functions this allows for
things like `ghcWithPackages.override { useLLVM = true; } (p: [ … ])`.
To make this possible for `ghcWithHoogle` as well, we need to make the
wrapper a bit more bespoke and inline the hoogle feature as well. The
hoogle wrapper, however, can remain separate and is exposed as
`hoogleWithPackages` additionally, as it can also serve standalone use.
`hoogleLocal` is kept for backwards compatibility (including the old,
suboptimal API), but will inform users about the better alternative via
a warning.
Overrideable functions are possible by wrapping them as functors in an
attribute set first and appending the overrideScope and override
attributes later.
cabal only allows one cabal file per directory and cabal2nix will find
the correct file easily. Thus we don't need to know ahead of time which
cabal file to select. One downside of this is of course that we may
include unnecessary files in subdirectories, which could possibly be
fixed by enforcing depth.
