Re: Non-Reinstallable packages

Dear friends, we have a set of non-reinstallable packages with GHC, these include iirc template-haskell, and some other. I've got a few questions concerning those: - do we have a complete up-to-date list of those? - why can't we reinstall them (let's assume we use the identical version for now; and don't upgrade) - does this also hold if we essentially build a stage3 compiler with packages? Our usual build process is: 1. take a boost-strap compiler, which doesn't need to have the same version as the final compiler. 2. build the libraries necessary to build the stage1 compiler while ensuring we build some extra libraries as well, so we don't have to rely on those shipped with the boot-strap compiler. 3. use the stage1 compiler to build all libraries we want to ship with the stage2 compiler; and build the stage2 compiler. Now I do understand that the stage1 compiler could potentially be tainted by the boot-strap compiler and as such yield different libraries compared to what the stage2 compiler would yield. Shouldn't rebuilding any library with the stage1 compiler yield the same libraries these days? If the boot-strap compiler is the same version as the one we build, shouldn't the stage2 compiler be capable of building good enough libraries as well so that we can reinstall them? What I ideally would like to have is a minimal compiler: ghc + rts; than keep building all the lirbaries from ground up. A potential problem I see is that if we use dynamic libraries and get into TH, we could run into issues where we want to link libraries that are different to the ones that the ghc binary links against. Would this also hold if we used `-fexternal-interpreter` only? Cheers, Moritz

Hi,
IIRC those packages can be "reinstalled", just build & register into a
fresh package database and add it to the pkgdb stack, ghc can shadow
the ones in the global pkgdb.
Regards,
Shao Cheng
On Tue, Aug 7, 2018 at 10:39 AM, Moritz Angermann
Dear friends,
we have a set of non-reinstallable packages with GHC, these include iirc template-haskell, and some other. I've got a few questions concerning those:
- do we have a complete up-to-date list of those? - why can't we reinstall them (let's assume we use the identical version for now; and don't upgrade) - does this also hold if we essentially build a stage3 compiler with packages?
Our usual build process is: 1. take a boost-strap compiler, which doesn't need to have the same version as the final compiler. 2. build the libraries necessary to build the stage1 compiler while ensuring we build some extra libraries as well, so we don't have to rely on those shipped with the boot-strap compiler. 3. use the stage1 compiler to build all libraries we want to ship with the stage2 compiler; and build the stage2 compiler.
Now I do understand that the stage1 compiler could potentially be tainted by the boot-strap compiler and as such yield different libraries compared to what the stage2 compiler would yield.
Shouldn't rebuilding any library with the stage1 compiler yield the same libraries these days?
If the boot-strap compiler is the same version as the one we build, shouldn't the stage2 compiler be capable of building good enough libraries as well so that we can reinstall them?
What I ideally would like to have is a minimal compiler: ghc + rts; than keep building all the lirbaries from ground up.
A potential problem I see is that if we use dynamic libraries and get into TH, we could run into issues where we want to link libraries that are different to the ones that the ghc binary links against. Would this also hold if we used `-fexternal-interpreter` only?
Cheers, Moritz
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (2)
-
Moritz Angermann
-
Shao, Cheng