Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward))

2017-07-24 Thread Herbert Valerio Riedel
Hi everyone,

As part of the recent GHC 8.2.1 release and the associated boot-library
publishing to Hackage, I picked up again experimenting with a
reinstallable lib:ghc package primarily for the benefit of uploading
haddocks for lib:ghc (w/ `--hyperlinked-source`) to Hackage:

  http://hackage.haskell.org/package/ghc

However, this also provides somewhat of a tech-preview of a
reinstallable lib:ghc package, which would help mitigate a big issue we
had in the past with lib:ghc and its dependencies being frozen to
specific versions, and which in combination with cabal's nix-style
pkg store that finally provide us with the ability to have multiple
instances of the same library versions co-existing in the same package
db, is no longer a requirement. So we could have lib:ghc more easily pick
dependencies up (but still within reason!) like e.g. lib:text without
forcing everyone to the single lib:text version bundled with GHC. And
we'd also gain the ability to publish patch-level releases to lib:ghc
only inbetween proper minor GHC releases (e.g. to support new versions
of library dependencies).

Consider this artificial example demo package which requires a different
version of binary than the one bundled with GHC 8.2.1:

--8<---cut here---start->8---
-- ghc-demo.cabal
name:ghc-demo
version: 0
build-type:  Simple
cabal-version:   >=2.0

executable ghc-demo
  main-is: Main.hs
  build-depends:   base ^>= 4.10, ghc ^>= 8.2.1, binary == 0.8.5.0
  default-language:Haskell2010
--8<---cut here---end--->8---

Trying to build this will have the cabal solver complain that the
installed instance of ghc requires a different (& installed) version of
binary, i.e. binary-0.8.5.1.

Moreover, the source version of lib:ghc on Hackage has the manual
`buildable` cabal flag which defaults to false, and currently prevents
lib:ghc to be reinstalled automatically (by enabling an unsatisfiable
constraint):

--8<---cut here---start->8---
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: base-4.10.0.0/installed-4.1... (dependency of ghc-demo-0)
next goal: ghc (dependency of ghc-demo-0)
rejecting: ghc-8.2.1/installed-8.2... (conflict: binary==0.8.5.0, ghc => 
binary==0.8.5.1/installed-0.8...)
trying: ghc-8.2.1
rejecting: ghc-8.2.1:-buildable (conflict: base==4.10.0.0/installed-4.1..., ghc 
-buildable => base<0)
rejecting: ghc-8.2.1:+buildable (manual flag can only be changed explicitly)
After searching the rest of the dependency tree exhaustively, these were the 
goals I've had most trouble fulfilling: ghc-demo, binary, base, ghc, 
ghc-8.2.1:buildable
--8<---cut here---end--->8---

However, if we unlock this by toggling the flag (NB: this only works on
linux/x86_64; it's explained later why), e.g.

--8<---cut here---start->8---
-- cabal.project file
packages: .

package ghc
  flags: +buildable
--8<---cut here---end--->8---

The cabal solver would come up with an install-plan:

--8<---cut here---start->8---
Resolving dependencies...
Build profile: -w ghc-8.2.1 -O1
In order, the following will be built (use -v for more details):
 - binary-0.8.5.0 
{binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac}
 (lib) (requires download & build)
 - ghc-boot-8.2.1 
{ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb}
 (lib) (requires build)
 - ghci-8.2.1 
{ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1} 
(lib) (requires build)
 - ghc-8.2.1 
{ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c} 
(lib) +buildable (requires build)
 - ghc-demo-0 {ghc-demo-0-inplace-ghc-demo} (exe:ghc-demo) (first run)

Configuring  
binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac 
(lib)
Building 
binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac 
(lib)
Installing   
binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac 
(lib)
Finished 
binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac 
(lib)
Configuring  
ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb 
(lib)
Building 
ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb 
(lib)
Installing   
ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb 
(lib)
Finished 
ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb 
(lib)
Configuring  
ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 
(lib)
Building 
ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 
(lib)
Installing   
ghci-8.2.1-6292924619a0

Re: Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward))

2017-07-24 Thread Joachim Breitner
Hi,

Am Montag, den 24.07.2017, 12:24 +0200 schrieb Herbert Valerio Riedel:
> Also, I'd like to know if you can think of reasons why or situations
> when the reinstalled lib:ghc wouldn't work; or other reasons why this
> is a bad idea.

I’d am mostly worried about ABI compatibility. Will the .hi files
written by the compiler be readable by some tool that was built with an
upgraded ghc? Which dependencies can affect the binary format (if any)?

Or will the rebuilt ghc get its own, randomly generated “GHC version”
(similar to a development build where the build date is part of the GHC
version) and hence never try to interact with build artifacts created
from the host ghc?


Also, if we can `cabal install ghc-the-library`, can we also `cabal
install ghc-the-program`, possibly at a different version? (It wouldn’t
be normally usable without bootstrapping a RTS and base library, but it
would be a step.)

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward))

2017-07-26 Thread Edward Z. Yang
Reinstalled GHC should be completely ABI compatible.  This should
actually not be difficult to achieve, since we already rely on this
in the GHC build system: we assume that ghc-stage1 generated hi files
can be compatibly read and used by ghc-stage2.

Excerpts from Joachim Breitner's message of 2017-07-24 15:04:21 -0400:
> Hi,
> 
> Am Montag, den 24.07.2017, 12:24 +0200 schrieb Herbert Valerio Riedel:
> > Also, I'd like to know if you can think of reasons why or situations
> > when the reinstalled lib:ghc wouldn't work; or other reasons why this
> > is a bad idea.
> 
> I’d am mostly worried about ABI compatibility. Will the .hi files
> written by the compiler be readable by some tool that was built with an
> upgraded ghc? Which dependencies can affect the binary format (if any)?
> 
> Or will the rebuilt ghc get its own, randomly generated “GHC version”
> (similar to a development build where the build date is part of the GHC
> version) and hence never try to interact with build artifacts created
> from the host ghc?
> 
> 
> Also, if we can `cabal install ghc-the-library`, can we also `cabal
> install ghc-the-program`, possibly at a different version? (It wouldn’t
> be normally usable without bootstrapping a RTS and base library, but it
> would be a step.)
> 
> Greetings,
> Joachim
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs