- Added the ability to generate coverage reports for packages and
projects.
- Outputs mix and tix information, as well as a HTML report.
- Added the "doCoverage" module option that allows users to choose
packages to enable coverage for.
- Added a "doCoverage" flag to the component builder that outputs HPC
information when coverage is enabled.
- Added the "overrideModules" library function to make it more
ergonomic fo users to enable coverage on existing projects.
- Modified the "check" builder to also output ".tix" files (if they
exist). This information is required to generate the coverage
report.
- Added a test for coverage.
* Changes to allow opencv to be built
The opencv library needs:
1. pkgconfig for opencv should return OpenCV 3, not OpenCV 2 (which is
what pkgs.opencv is)
2. hardeningDisable = [ "bindnow" ] (as per
https://github.com/LumiGuide/haskell-opencv/commit/5ea490af7662fe74b3740619963d37f1fd91e3d4#)
This commit fixes (1) by adding an entry to lib/pkgconf-nixpkgs-map.nix,
and partially fixes (2) by adding a new `hardeningDisable` option to the
set of package options. The user will still need to specify:
packages.opencv.hardeningDisable = [ "bindnow" ];
I'm not sure if there's a place to specify this as default in haskell.nix.
* Update comp-builder.nix
Currently the `dummy-ghc-data`, `nix-tools` plan and `cabal-install`
plan must be materialized for the selected `ghc`. This change
relaxes that restriction and will instead use `nix-tools` and
`cabal-install` built with a fixed `ghc` version (currently `ghc865`)
and will calculate the `dummy-ghc-data` as an IFD.
It will `__trace` a warning of the form:
```
WARNING: No materialized dummy-ghc-data for ghc-8.6.4-x86_64-darwin.
```
It is now possible to specify multiple subdirs in a
`source-repository-package` block. This change fixes the parser
code in haskell.nix so that it understands.
```
cleanGit {
src = cleanSrcWith { ... }
}
```
Results in the full `src` being copied to the store before filtering
the files not in the git index.
This change uses `src.origSrcSubDir` if it exists to avoid this.
It causes a lot of issues. To make this work:
* `shellFor` is updated to use `getAllComponents` instead of `.all`.
* `getAllComponents` is updated to work on the package rather than
the package config.
* Tests updated to not use `.library` or `.exes.X` where appropriate.
* Documentation updated.
* Out of date examples removed.
As a bonus `shellFor` now takes a `components` argument that might be
useful for limiting the dependencies of the shell to just the ones
needed for the components you intend to work on.
Changes to the interface of haskell.nix (from the changelog.md file):
* Removed `sources.nixpkgs-default`, use `sources.nixpkgs` instead.
* Removed `./nixpkgs` directory, use `(import ./. {}).sources`
or `./nix/sources.nix` instead.
* Removes V1 interface for details on how to fix old code see:
https://github.com/input-output-hk/haskell.nix/issues/709
* Removed defaultCompilerNixName.
* cabalProject, cabalProject', hackage-project and hackage-package
now require a `compiler-nix-name` argument.
* `haskell-nix.tool` and `.tools` now require a `compiler-nix-name` argument.
New functions `p.tool` and `p.tools` (where p is a project) do not.
Like `shellFor { tools = ... }` they will use the compiler nix name
from the project (including stack projects where it is derived from
the resolver).
* `haskell-nix.alex` and `haskell-nix.happy` have been removed. Use
`p.tool "alex" "3.2.5"` or `shellFor { tools = { alex = "3.2.5"; } }`.
* `haskell-nix.nix-tools` -> `haskell-nix.nix-tools.ghc883` (it includes
the hpack exe now).
* `haskell-nix.cabal-install` ->
`p.tool "cabal" "3.2.0.0"` or `shellFor { tools = { cabal = "3.2.0.0"; } }`
* `haskell-nix.haskellNixRoots` -> `haskell-nix.roots ghc883` or `p.roots`
Other changes:
Adds hpack executable to the nix-tools derivations.
Adds a `cabal-hpack` test to make sure `hpack` works with
`cabalProject`.
Reduces the number of calls to `cabalProject` (particularly when
checking materialization), by giving internal tools a per-compiler
attribute.
Uses happy 1.19.12 when building newer ghc versions.
Updates cabal-install 3.2.0.0 to use the source from github that
is compatible with ghc 8.10.1.
Updates the docs for callCabalProjectToNix.
Adds a license mapping to fix a common warning.
This change allows a resolverSha256 to be passed to stackProject.
When provided the resolver found in the stack.yaml is fetched
using this sha256 and the uri string is replaced with the
path to the fetched version.
This is a simple way to specify the sha256 values for references
to git repositories that do not have a `--sha256:` comment in the
`cabal.project` file or a `# nix-sha256:` comment in the `stack.yaml`
file.
The tests demonstrate how to use `sha256map` with both
`cabalProject` and `stackProject` to build the
haskell-language-server from github with the sha256 hashes
needed to work with `--option restrict-eval true`.
Fixes#672 by using the first index-state that is > than desired
index state. It also passes `--index-state` to `cabal v2-cconfigre`
to make sure it cabal uses only the packages in the hackage
file that are before the specified date.
Fixes#540 by returning the `index-state` used back out of
`cabalProject` in the same way `plan-nix` is returned.
* Add script for fixing materialized files
This is useful in two ways:
- We reference it in the error message, so users can more easily
copy-paste the correct call, rather than several lines of commands.
- We add it to `passthru`, so users can reference it directly when they
know they need to update the files, without having to first run a build
and find it on stderr.
* Add script for calculating the sha
This is useful in two ways:
- It makes it easier for users to copy from the message.
- We add it to `passthru` so users can call it directly if they know
they need to update the sha, without having to run a build and copy it
from stderr.
* Refactor unchecked a bit
Put the positive logic first, use the materialized files by preference
if they're there.
* Allow the updater script to take an argument
* Use double brackets
* Fix a dependency
* Separate generating and updating scripts
* ghc 8.10
* Adds/Updates/Removes materialization files
* Disable one-shot-kqueue-on-macos patch on ghc-8.10
* Test ghc883 and ghc8101 but only with nix 20.03
* Various smaller fixes.
This should fix the infinite recursion issue with #654
Co-authored-by: Lennart Spitzner <hexagoxel@hexagoxel.de>
Running `cabal v2-configure` overwrites the `cabal.project.local` file
so this change adds the contents onto the end of the `cabal.project`
file before running `cabal v2-configure`.
You can override this behavior passing `cabalProjectLocal = ""`
Treats cabal.project.feeze the same way as `cabal.project` and
`cabal.project.local` in that it will still use it if it is filtered by cleanGit.
This change also adds `cabalProjectFileName` arg so that
we can override the default `cabal.project` name.
This change improves the dummy ghc scripts by adding a bang pattern,
supporting `--version` and using bash case instead of lots of `elif`
Includes the same fixes for dummy-ghc-pkg
Some times it is handy to temporarily use a relative path between git
repos. If the repos are individually cleaned this is not possible
(since the cleaned version of one repo will never include the files
of the other).
`cleanGits` allows us to specify a root directory and any number of
sub directories containing git repos.
When the `license-file` is not at the top-level, e.g. in the LICENSES
subdirectory, it didn’t have any chance of being included, as the
subdirectory was filtered out right away.
Include `licenseFiles` in the list of subdirs used for determining
“needed” subdirectories (the ones that will be kept).
Although the default ghc used by haskell.nix is ghc 8.6.5 many of
the tools used in haskell.nix are still built with the boot compiler
ghc 8.4.4. These include
* haskell-nix.cabal-install
* haskell-nix.alex
* haskell-nix.happy
This change updates those to ghc 8.6.5 and includes materializations
for the new versions.
When cabal-install is built it is careful to disable materialization
checks on the version of itself used during the build to avoid
infinite recursion.
There was a version of nix-tools built with the boot ghc which was
only used when `checkMaterialization = true`. It was used for
the boot versions of alex, happy and hscolour. These have been update
to use the default (ghc 8.6.5) version of nix-tools and
checkMaterialization is forced off when they are being used to build
ghc. This means the materialization will only be checked for these
when they are built independently (they are included in the test set
via haskellNixRoots).
Three new arguments are added to `default.nix`:
* `defaultCompilerNixName` if not specified "ghc865" is used
* `checkMaterialization` makes it easier to switch on materialization checks
* `system` defaults to `builtins.currentSystem`
This change also moves the work needed for hydra eval to the eval
system using a new `evalPackages` feature. This includes:
* Fetching from git with `fetchgit`
* Building scripts with `runCommand` and `writeTextFile`
* `git ls-files` in `cleanGit`
* running `cabal v2-configure`
* copying materialized files (we are not sure why this is necessary but
if we do not `cp -r` the files nix will not load them on hydra)
Reduce size of `make-config-files.nix` strings by around 80%.
These are unlikely to be the cause of hydra eval time memory
issues in the GB range, but were still quite large (around 10MB for the
`cabal-simple` test case).
There was issue causing excessive builds of the `git` package when
cross compiling. Gory details are a comment in `lib/defaults.nix`
but in short if you use `git` you need an extra `.buildPackages`
one is not enough because it depends on `gdb` and that will
be different in `buildPackages` compared to
`buildPackages.buildPackages`.
Adds missing materialization files for ghc 8.4.4 (only needed
when `checkMaterialization` is on because of other
materialiazations, but good to have).
* Add compiler-nix-name to cabalProject
Setting the compiler explicitly does not make it easy for cross
compilation to also choose the correct compiler when compiling
build tools for the build platform. Also it is easy to pass the
wrong compiler type. Specifying just the nix-name of the compiler
makes that less likely.
Co-authored-by: Moritz Angermann <moritz.angermann@gmail.com>
The `cabalProject` function works by running `cabal v2-configure` followed by `plan-to-nix`. However for `v2-configure` to correctly calculate the plan (including flag settings and buildable components) it needs to know what GHC we want to use.
This causes significant problems:
* For hydra to assemble a list of jobs from `components.tests` it must first have GHC that will be used. If a patch has been applied to the GHC to be used it must be rebuilt before the list of jobs can be assembled. If a lot of different GHCs are being tests that can be a lot of work all happening in the eval stage where little feedback is available.
* Once the jobs are running the compilation of the GHC needed (the eval stage already must have done it, but the outputs there are apparently not added to the cache) happens inside the IFD part of `cabalProject`. This causes a very large amount of work to be done in the IFD and our understanding is that this can cause problems on nix and/or hydra.
* When using `cabalProject` we cannot examine the properties of the project without building or downloading the GHC (less of an issue as we would normally need it soon anyway).
The solution here is to:
* Create a dummy `ghc` and `ghc-pkg` from the real ones by capturing the `ghc` and `ghc-pkg` outputs that `cabal v2-configure` requests.
* The dummy `ghc` and `ghc-pkg` is used instead of the real one in `cabalProject` when running `cabal v2-configure`.
* The captured outputs are materialized into the haskell.nix repo so that the real GHC is only needed when `checkMaterialization` is set.
* Add native musl support
- adds haskellLibl.isNaviveMusl and related fixes (previously it was
assumed that for musl we always use cross-compilation)
- fixed some issues for musl intoduced in nixpkgs 20.03 (ssh/fetchcvs
infinite recursion, busybox pkgsMusl.pkgsStatic chain, etc.)
- cross-compilation fixes for ghc (absolute path for ar, always pass
target to configure, libffi and gmp packages for target platform) -
this needs more testing
* Better explanation for targetPlatform.{libffi, gmp}
* Ghc configure script now respect AR env variable
Co-authored-by: Moritz Angermann <moritz.angermann@gmail.com>