cheng.shao at tweag.io
Tue Aug 7 02:51:15 UTC 2018
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.
On Tue, Aug 7, 2018 at 10:39 AM, Moritz Angermann
<moritz.angermann at gmail.com> wrote:
> 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
> 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?
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs