Although purescript-{cst,ast} don't depend on purescript, it's important
that they use the same dependencies as the latter, so packages that
depend on more than one of them at the same time work, like e.g.
purenix (which is broken at the moment because it doesn't support
purescript 0.15).
After a dependency got unbroken recently, only a patch for LTS 18 which
is now part of the release needed cleaning up and aeson 1.5.* and
corresponding bower-json version to be provided.
the `lhs2tex` tool is a “commonly” used tool in academia to typeset
certain papers, and it would be prudent to have it available outside the
`haskellPackages` namespace, and also made available on the caches.
Also added to release-haskell.nix, and made myself the maintainer.
The xhtml library is only built as part of the GHC build process if GHC
is disabled. This means that no GHC cross compiler has xhtml bundled,
since haddock can't be built if GHC is a cross compiler (see relevant
notes in the GHC nix expressions). This means that all packages
depending on xhtml would currently fail to build when cross-compiled, as
haskellPackages would assume it'd be provided by GHC. This is fixed by
this commit.
pkgsStatic hits this case, so we test compilation of xhtml for these
package sets which will remind us to update the attribute name whenever
its version changes.
* Test the default pkgsStatic.haskellPackages set, as it should be
working properly now.
* Instead of GHC 8.10.7 which hasn't gotten some workarounds applied,
test GHC 9.2.2 additionally which should work as well as GHC 9.0.
* Test building an actual executable, cabal2nix.
* Simplify aggregate job definition.
* Make sure GHC 9.2 lens gets built on Hydra.
By telling Hydra where to look explicitly, it can be instrumented
to build the boot ghcjs which is only about 300MB. This saves at
least some time compiling for users and will also provide some
eval CI automatically.
rustc fails to build on x86_64-darwin on the M1 builders Hydra uses.
Since GHC depends on rustc (sphinx -> cryptography -> GHC), the entire
darwin package set is broken at the moment, cluttering build reports
etc.
Expose from haskell.packages.ghc921 (which is the only GHC version that
can build it easily atm) and additionally install man page, language
guide and code examples.
GHC 9.2.1 has grown beyond being a release candidate for quite some time
now, so let's also adjust the released shortcut in the jobset
definition. ghc-api-compat and haskell-language-server still don't
support 9.2.1, however.
haskell.packages.ghc921.bsb-http-chunked: disable doctest suite
This package's doctest suite is invoked in a weird way apparently which
makes it fail to typecheck with GHC 9.2.1.
mach-o executables we produce in writers are not always fully valid for
some reason. In normal derivation this is fixed in fixupPhase and we can
replicate this behavior here easily.
Resolves#132660.
* haskell.packages.ghc884.ghc-api-compat needed us to re-add the 8.6
version of the package.
* haskell.packages.ghc901.ghc-api-compat now points to the newly
released 9.0.1 version of the package.
* haskell.packages.ghc8107.ghc-api-compat now correctly points to
ghc-api-compat 8.10.7.
GHC 9.2.1 is still unsupported (which is to be expected, with it
being a release candidate).
To make sure everything stays working we'll build ghc-api-compat as part
of versionedCompilerJobs.
The only big change is required for darwin since GHC 8.10.5 now
runs xattr in the install phase on darwin:
* 11e1dcde0d
* ec451cac39
Unfortunately, it uses the host /usr/bin/xattr by default which is
present in the build due to a lack of sandboxing on darwin. That xattr
version however still requires Python 2.7 whereas Python 3.8 is in PATH
in our build. We solve this by setting the XATTR environment variable.
We can't use python3Packages.xattr since GHC expects Apple's fork of
xattr which provides some extra flags to utilize.
Co-authored-by: Cheng Shao <cheng.shao@tweag.io>
The statically-linked Haskell packages on Darwin are not currently
working because libiconv is not building statically on Darwin.
The statically-linked Haskell packages on aarch64 are timing out on Hydra.
Since the agda compiler is updated via haskellPackages.Agda, we are
quite likely to cause regressions in agdaPackages when the language is
changed via compiler updates. Thus we should build agdaPackages (which
is very small) as part of the haskell-updates jobset and track if
basic agda functionality (compiler and standard library) is working.
Since the rust writer doesn't seem to get fixed on darwin, we'll just
wrap the haskell writer test in our own derivation (which is possible
since tests.writers exposes a bunch of internals via passthru) and
expose it via tests.haskell which are already in mergeable.
Finally a way to test the (hopefully) working haskell writer on darwin
again!
Since libiconv doesn't build in pkgsStatic on darwin, having these
builds in our aggregate jobset are just gonna make it fail due to reason
not really in scope for our jobset here.
This way we can keep track of any new regressions to this as well as
have some binary cache, so using this infrastructure doesn't require
compiling GHC all the time.
We have different attribute sets defining jobs: The list of base jobs,
the ones generated by versionedCompilerJobs and our added aggregate
jobs. During this we define `haskell` twice: Once for `haskell.compiler`
and once for `haskell.packages.*`. The `//` operator throws a way the
former which is fixed by using lib.recursiveUpdate.
Unfortunately makes the expression less pretty, but at least we have our
compiler jobs back.
top-level/release.nix builds haskellPackages on those systems as well,
so we should test on them as well. Currently we have virtually no
insight into the state on there.
These should now also include all packages that use haskellPackages in
some form where it is apparent from all-packages.nix.
Some of those probably could do with a cleanup (maybe fetchable from
hackage, many are missing justStaticExecutables).
release-haskell.nix is intended to be a replacement for
https://github.com/peti/ci/blob/master/haskell-nixpkgs.nix
which is currently the main expression for the haskell-updates jobset
on hydra (in the nixpkgs project).
It has the same jobs as the old haskell-nixpkgs.nix file:
* haskellPackages.*
* haskell.compiler.*
* Some extra haskell packages for certain compilers
The following jobs are new:
* tests.haskell.*
* A manually maintained list of top-level haskell packages (most of them
using justStaticExecutables)
* An aggregate job which is intended to aid merging the haskell-updates
branch: It holds an arbitrary list of haskell-related packages and
tests we intend have working at all times. This is still somewhat
incomplete and should be extendend in the future.
Additionally a lot of refactoring has been done and some unnecessary
code has been eliminated. Due to the increased set of jobs and my
ideas of convenience however, the code size has grown overall.
I've tried document the individual parts and would be happy about
feedback in general.
One future improvement could be making adding top-level haskell packages
more convenient and adding them all to the aggregate job automatically.
The new job set has the following structure:
pkg.ghc762.x86_64-linux = pkgs_x86_64_linux.haskellPackages_ghc762.pkg;
pkg.ghc762.i686-linux = pkgs_i686_linux.haskellPackages_ghc762.pkg;
pkg.ghc6123.x86_64-linux = pkgs_x86_64_linux.haskellPackages_ghc6123.pkg;
pkg.ghc6123.i686-linux = pkgs_i686_linux.haskellPackages_ghc6123.pkg;
This gives us (in theory) the ability to generate a Hydra page that displays
the build status of a package across all versions of GHC and all systems. Right
now, Hydra is not up to it, but Eelco says the feature is "on the todo list".
This file doesn't specify the supported build systems explicitly. Instead, that
information is taken from the respective pkg.meta.platforms attribute.
