Re: Non-Reinstallable packages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Non-Reinstallable packages

Moritz Angermann-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-Reinstallable packages

Shao, Cheng
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
<[hidden email]> 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
>   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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs