2020-09-22 11:35:39 +00:00
|
|
|
{ lib, stdenv, haskellPackages, cabal-install }:
|
shellFor: Refactor for consistency and cross
This makes it work like work-on-multi from Reflex Platform. In
particular, rather than making `.env` from `shellFor`, we make `.env`
the primitive, and `shellFor` works by combining together the arguments
of all the packages to `generic-builder` and taking the `.env` of the
resulting mashup-package.
There are 2 benefits of this:
1. The dependency logic is deduplicated. generic builder just concatted
lists, whereas all the envs until now would sieve apart haskell and
system build inputs. Now, they both decide haskell vs system the same
way: according to the argument list and without reflection.
Consistency is good, especially because it mean that if the build
works, the shell is more likely to work.
2. Cross is handled better. For native builds, because the
`ghcWithPackages` calls would shadow, we through both the regular
component (lib, exe, test, bench) haskell deps and Setup.hs haskell
deps in the same `ghcWithPackages` call. But for cross builds we use
`buildPackages.ghcWithPackages` to get the setup deps. This ensures
everything works correctly.
2019-12-23 20:33:18 +00:00
|
|
|
|
2020-09-22 11:35:39 +00:00
|
|
|
(haskellPackages.shellFor {
|
|
|
|
|
packages = p: [ p.database-id-class p.constraints ];
|
shellFor: Refactor for consistency and cross
This makes it work like work-on-multi from Reflex Platform. In
particular, rather than making `.env` from `shellFor`, we make `.env`
the primitive, and `shellFor` works by combining together the arguments
of all the packages to `generic-builder` and taking the `.env` of the
resulting mashup-package.
There are 2 benefits of this:
1. The dependency logic is deduplicated. generic builder just concatted
lists, whereas all the envs until now would sieve apart haskell and
system build inputs. Now, they both decide haskell vs system the same
way: according to the argument list and without reflection.
Consistency is good, especially because it mean that if the build
works, the shell is more likely to work.
2. Cross is handled better. For native builds, because the
`ghcWithPackages` calls would shadow, we through both the regular
component (lib, exe, test, bench) haskell deps and Setup.hs haskell
deps in the same `ghcWithPackages` call. But for cross builds we use
`buildPackages.ghcWithPackages` to get the setup deps. This ensures
everything works correctly.
2019-12-23 20:33:18 +00:00
|
|
|
nativeBuildInputs = [ cabal-install ];
|
|
|
|
|
phases = [ "unpackPhase" "buildPhase" "installPhase" ];
|
|
|
|
|
unpackPhase = ''
|
|
|
|
|
sourceRoot=$(pwd)/scratch
|
|
|
|
|
mkdir -p "$sourceRoot"
|
|
|
|
|
cd "$sourceRoot"
|
|
|
|
|
tar -xf ${haskellPackages.database-id-class.src}
|
2020-09-22 11:35:39 +00:00
|
|
|
tar -xf ${haskellPackages.constraints.src}
|
|
|
|
|
cp ${builtins.toFile "cabal.project" "packages: database-id-class* constraints*"} cabal.project
|
shellFor: Refactor for consistency and cross
This makes it work like work-on-multi from Reflex Platform. In
particular, rather than making `.env` from `shellFor`, we make `.env`
the primitive, and `shellFor` works by combining together the arguments
of all the packages to `generic-builder` and taking the `.env` of the
resulting mashup-package.
There are 2 benefits of this:
1. The dependency logic is deduplicated. generic builder just concatted
lists, whereas all the envs until now would sieve apart haskell and
system build inputs. Now, they both decide haskell vs system the same
way: according to the argument list and without reflection.
Consistency is good, especially because it mean that if the build
works, the shell is more likely to work.
2. Cross is handled better. For native builds, because the
`ghcWithPackages` calls would shadow, we through both the regular
component (lib, exe, test, bench) haskell deps and Setup.hs haskell
deps in the same `ghcWithPackages` call. But for cross builds we use
`buildPackages.ghcWithPackages` to get the setup deps. This ensures
everything works correctly.
2019-12-23 20:33:18 +00:00
|
|
|
'';
|
|
|
|
|
buildPhase = ''
|
|
|
|
|
export HOME=$(mktemp -d)
|
|
|
|
|
mkdir -p $HOME/.cabal
|
|
|
|
|
touch $HOME/.cabal/config
|
2020-09-22 11:35:39 +00:00
|
|
|
cabal v2-build --offline --verbose database-id-class constraints --ghc-options="-O0 -j$NIX_BUILD_CORES"
|
shellFor: Refactor for consistency and cross
This makes it work like work-on-multi from Reflex Platform. In
particular, rather than making `.env` from `shellFor`, we make `.env`
the primitive, and `shellFor` works by combining together the arguments
of all the packages to `generic-builder` and taking the `.env` of the
resulting mashup-package.
There are 2 benefits of this:
1. The dependency logic is deduplicated. generic builder just concatted
lists, whereas all the envs until now would sieve apart haskell and
system build inputs. Now, they both decide haskell vs system the same
way: according to the argument list and without reflection.
Consistency is good, especially because it mean that if the build
works, the shell is more likely to work.
2. Cross is handled better. For native builds, because the
`ghcWithPackages` calls would shadow, we through both the regular
component (lib, exe, test, bench) haskell deps and Setup.hs haskell
deps in the same `ghcWithPackages` call. But for cross builds we use
`buildPackages.ghcWithPackages` to get the setup deps. This ensures
everything works correctly.
2019-12-23 20:33:18 +00:00
|
|
|
'';
|
|
|
|
|
installPhase = ''
|
|
|
|
|
touch $out
|
|
|
|
|
'';
|
2020-09-22 11:35:39 +00:00
|
|
|
}).overrideAttrs (oldAttrs: {
|
|
|
|
|
meta =
|
|
|
|
|
let
|
|
|
|
|
oldMeta = oldAttrs.meta or {};
|
|
|
|
|
oldMaintainers = oldMeta.maintainers or [];
|
|
|
|
|
additionalMaintainers = with lib.maintainers; [ cdepillabout ];
|
|
|
|
|
allMaintainers = oldMaintainers ++ additionalMaintainers;
|
|
|
|
|
in
|
|
|
|
|
oldMeta // { maintainers = allMaintainers; };
|
|
|
|
|
})
|