* Add hydraJobs.devShell and flatten hydraJobs
Also moves the `rawFlake` code into a `haskellLib.mkFlake` function
* Unflatten hydraJobs and add ciJobs
It turns out it is nice to use system first in the hierarchy for cicero. Also both hydra and cicero are ok with a deep hierarchy of attributes.
* Refactoring
* Add mkFlakeCiJobs
* Avoid `:` in ciJobs and hydraJobs
* Use cabal names again in ciJobs
* More updates
Turns off code coverage by default.
Rename flattenChecks to mkFlakeChecks.
Adds flake packages to ciJobs and hydraJobs.
* Expand comment
In the past hydra didn't give good feedback on eval time errors. Deferring the errors was a way to get them into a build log (instead of the eval log that would get overwritten with the next eval).
I'm not sure how well this actually worked since it is super easy to introduce an eval time dependency on a broken project. For instance if you try to enumerate the components in a project haskell that failed to configure the error would be forced (in some cases a more cryptic one).
Now that hydra is better at reporting eval errors I think we should try to fail fast again.
* update llvm-hs llvm from 11 to 12
* allow passing version args to build-tools; fix llvm-hs build-tools, pass allRefs to builtins.fetchGit to allow fetching non-standard-refs (to mirror stack behaviour)
* Fix regex to match source-repository-package tag
Regex to tell ref from rev was wrong
* Fix fetchGit call when rev and sha256 unspecified
* Update expected output for unit test
* Auto retry concurrency check that keeps failing
Co-authored-by: Hamish Mackenzie <Hamish.K.Mackenzie@gmail.com>
* Fix ghcjs for time_t is 64bit in emscripten now.
* Fix error: qca2 has been removed, because it depended on qt4.
* Add spdx 3.18 materialization.
* Turn off building tests for wine-5.4 (due to IDL issue).
* Fix options-doc.nix.
* Comment added to force rebuild on hydra
* Remove webkitgtk24x-gtk3 mapping
Even just looking for `pkgs.webkitgtk24x-gtk3.version` crashes nix eval with:
```
error: webkitgtk24x-gtk3 has been removed because it's insecure. Please use webkitgtk.
```
* Pin hlint for tests
* Pin hlint for tests
* Add flake.variants
This allows flakes to easily include variations of the
project by with different project arguments.
Anything you can pass to `project.addModule` can be used.
For instance to include variants using ghc 9.2.4:
```
flake.variants.ghc924.compiler-nix-name = pkgs.lib.mkForce "ghc924";
```
Then use it with:
```
nix build .#ghc924:hello:exe:hello
```
This change also:
* Exposes add `combineFlakes` and `rawFlake` for more control over how flakes are combined.
* Includes package coverageReports to the `hydraJobs` of the flakes.
* Tries to make the materialisation concurrency test more reliable
* Determine if the tag is a ref or a rev
Test the `tag` attribute in the `cabal.project` file. If it looks like a
git hash, then assign it to `rev`. Otherwise, assign it to `ref`.
* ok
* ok
* lmao
* Address comments
* better if not present
* patch hpc to allow files to be used for the list of src dirs, hpc dirs, and includes
* delete trailing whitespace
* use Response Files for HPC arguments; delete unnecessary patch
* Add ghc patch based on what was merged upstream
* Fix coverage tests
* Update responseFile usage
* Enable coverage-no-libs test
Co-authored-by: Richard Wallace <rwallace@thewallacepack.net>
Co-authored-by: Hamish Mackenzie <Hamish.K.Mackenzie@gmail.com>
#1588 does not provide an implicit project the way cabal does. So for instance:
```
$ cabal unpack hello
$ cd hello-1.0.0.2
$ echo 'constraints: hello<0' >cabal.project.local
$ cabal build all
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] next goal: hello (user goal)
[__0] rejecting: hello-1.0.0.2 (constraint from project config
/Users/hamish/iohk/hello-1.0.0.2/cabal.project.local requires <0)
[__0] rejecting: hello-1.0.0.1, hello-1.0 (constraint from user target
requires ==1.0.0.2)
[__0] fail (backjumping, conflict set: hello)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: hello
```
So even though there was no `packages:` it is looking for the package in the default location (the default is `packages: ./*.cabal` according to the cabal docs).
I also checked that including `packages:` in `.local` does not change the implicit `packages: ./*.cabal` with:
```
$ cabal unpack split
$ echo 'packages: ./split-0.2.3.5' > cabal.project.local
$ cabal build hello:exe:hello split:lib:split
```
This adds support for using nix flakes commands with hix. This is done by creating a hidden `.hix-flake` directory and passing the source in using `--override-input`.
It also includes a `hix init` command to add a `flake.nix` and `nix/hix.nix` configuration file.
New versions of `srcOnly` pass the `prePatch` hook in and we `cd` into the sub directory for the package in that hook. This means that the output includes only the package subdirectory.
We worked around this, but the work around breaks for older nixpkgs where `prePatch` is not passed.
This change replaces the use of `srcOnly` and instead uses the same trick as source so that the `buildPhase` is replaced and runs in the expected source directory (including and it should still include any sibling directories that have not been filtered).
This adds a way to specify the `evalSystem` or `evalPackages` explicitly when calling the `project` functions.
Currently if we want to make a `flake` that supports multiple systems we have few options:
* Require builders for all the supported systems (even just for `nix flake show`).
* Pass `--impure` so that haskell.nix can see `builtins.currentSystem` to set up `pkgs.evalPackages` to use that. Unfortunately this prevents nix from caching some of the work it does and often results in it recalculating for each supported system when it would otherwise be cached and take no time at all.
* Add an overlay to replace `evalPackages`. This works, but it is not straight forward.
* Materialize the nix files for the project.
This change allows `evalSystem = "x86_64-linux";` to be passed telling `haskell.nix` to run `cabal` and `nix-tools` on that system. The user will have to have a builder for that system, but does not need to have builders for the others (unless building outputs for them).
* Provide an empty coverage report when package has no coverage
- When covering a project with multiple packages, the project coverage report
will produce a table of individual coverage reports for each package. The
links in this table don't go anywhere when a package is uncovered (they are
broken links).
- By producing an empty coverage report when a package has no coverage, we fix
the broken links, and provide a tad more information about the coverage
state of that package.
* Improve project coverage report index page
- Provide a link to the union/all coverage report.
- Format the reports as a list instead of a table of one column.
- Provide better explanation of what each report means.
* Add warning explaining modules with no coverage
- Modules that have no coverage at all are simply not included in the HTML
reports generated by HPC.
- Add a warning to the project coverage report index page so users are aware of
this limitation of HPC.
* Simplify interface of coverageReport
- Remove the concept of "package boundaries" from the "coverageReport" function.
- The "coverageReport" is now a function of:
- arbitrary checks generating tix files
- arbitrary mix modules
- This more closely reflects the usage of hpc, which doesn't care about package
boundaries.
- Use this new "coverageReport" function to simplify the "projectCoverageReport"
implementation. A project coverage report now simply:
- copies out constituent coverage reports.
- writes out an "all coverage report" using all checks in the project and all
mix modules..
- writes out a summary index page.
since it needs custom shell setup and knowledge not wanted/necessary for
many project. cabalWrapper can still be used from iohk-nix, until
underlying issue is handled natively by cabal.
Also remove packagesExes materialization attributes,
not really useful anymore, given faster evaluation of recent haskell.nix
Currently haskell.nix uses IFDs internally in a number of places. This prevents the use of `--option allow-import-from-derivation false` even when `materialized` nix is provided.
* Changes `materialize` function so that it returns the `materialized` path when possible instead of a derivation (updates import-and-filter-project.nix to cope with that).
* Materializes the spdx json file.
* Prevents haskell.nix looking for `cabal.project`, `cabal.project.local` and `cabal.project.freeze` files in hackage packages and the ghc-extra-projects.
Fixes Windows cross compilation for GHC 9.0 and 9.2.
Updates wine to use the version that is included with the chosen Nixpkgs (it used to be pinned to an older version).
Moves the configuration of the GHC source into the GHC derivation. This should make adding Hadrian support easier.
Propagates library dependences (not just pkgconfig ones) on windows so that any DLLs in those libraries can be copied for TH evaluation and to the `/bin` directory of executable components.
Adds gcc and mfcgthreads as library dependencies on Windows so that the DLLs they include will be found.
Use `$pkgsHostTarget` (instead of `ghc-pkg`) to find all the DLLs can copy them to the `/bin` directory of executable components.
Adds support for __int128_t and __uint128_t to language-c to fix aarch64-darwin builds.
Fixed reinstalling packages that come with patched versions in ghcjs.
Suppose you have a repository with a submodule checked out in the
subdirectory `smod`.
`cleanGit { src = ./smod; }` would return the following error:
error: getting status of '/.git/modules/smod': No such file or directory
`smod/.git` is a file that contains a reference to the git module repo.
gitdir: ../.git/modules/smod
This is the same as a worktree (in fact, isWorktree = true here),
but it's a relative path instead of an absolute path.
Co-authored-by: Ewout Van Troostenberghe <evantroostenberghe@hubspot.com>
When downloading a `repository` block we get a number of files (not just the index). For some repositories these files will be necessary for `cabal configure` and the vanilla ones created by haskell.nix will not work. This change keeps these extra files and combines them with the main hackage index using `lndir`, so that changes to the repo will not require a new copy of the hackage index in the store.
This change also introduces `inputMap` that allows flake or niv inputs to be used to pin repository. It also works with `source-repository-package` blocks.
* Downgrades the error to a warning.
* Adds `filterPath` as a way to disable filtering to have caching work between Nix <2.4 and >=2.4.
* Disables filtering on `haskell-nix.hackage-project` based functions (should make all the GHC derivations the same).
I think it would also be possible to make a `filterPath` implementation that recursively used `builtins.readDir` and called the `filter` function to implement filtering on Nix <2.4, but I am not sure if it is worth it.
Anyone that needs the old behaviour for project packages (consistent filtering between <2.4 and >=2.4, but not between store and local) replace:
```
project = pkgs.haskell-nix.cabalProject {
src = pkgs.haskell-nix.haskellLib.cleanGit {
src = ./.;
};
};
```
```
project = pkgs.haskell-nix.cabalProject {
src = pkgs.haskell-nix.haskellLib.cleanGit {
src = {
outPath = ./.;
filterPath = { path, ... }@args:
if builtins.hasContext (toString path) then path else builtins.path args;
};
};
};
```
In recent nix, builtins.path works in restricted eval mode.
Therefore canCleanSource is not required anymore.
follow up on #1403
* add comment on hydra overlay
* throw error on outdated nix version
Jean-Baptiste Giraudeau
Hamish Mackenzie
Mango The Fourth
Maxim Koltsov
Matt Parsons
Peter Becich
Armando Ramirez
Las Safin
Yvan Sraka
Yvan Sraka
Samuel Evans-Powell
Robert Hensing
Sascha-Oliver Prolic
Daniel Firth
Ewout
paumr
DavHau
Carsten Csiky