Re: Core-updates after the staging merge

[Simon Tournier]

Hi,

On lun., 17 avril 2023 at 16:12, Lars-Dominik Braun <lars@6xq.net> wrote:

> note that the information on haskell.org is not always accurate and thus
> this shorter chain may not actually work. Please give it a try and send
> a patch.

If I read correctly, the current chain is:

           7.8.4
        -> 7.10.3
        -> 8.0.2
        -> 8.4.4
        -> 8.6.5
        -> 8.8.4
        -> 8.10.7
        -> 9.0.2; 9.2.5
        -> 9.4.4 (next)

where 9.2.5 is the one used by haskell-build-system.  Instead, this
chain,

           7.8.4  (needs 7.4 at least)
        -> 8.0.1  (needs 7.8 at least)
        -> 8.4.4  (needs 8.0 at least)
        -> 8.6.5  (needs 8.2 at least)
        -> 8.10.7  (needs 8.6 at least)
        -> 9.2.5  (needs 8.10 at least)

builds for me.  So It removes 7.10.3 and 8.8.4.


That said, note that the current binary root is 7.8.4 with the hope to
join with the current,

           4.08.2 (needs GCC and outputs of previous GHC)
        -> 6.0    (needs 4.08 at least)
        -> 6.6    (needs 5.04 at least)
        -> 6.10.4 (needs 6.6  at least)

Well, joining 9.2.5 to 4.08.2 could be done using intermediary versions:

-> 6.10.4 (needs 6.6  at least)  | -> 6.10.4 (needs 6.6  at least)
   6.12.3 (needs 6.8  at least)  |    7.2.2  (needs 6.10 at least)
   7.4.2  (needs 6.12 at least)  |    7.6.3  (needs 7.0  at least)
   7.8.4  (needs 7.4 at least)   | -> 7.10.3 (needs 7.6  at least)
-> 8.0.1  (needs 7.8 at least)   |    8.2.2  (needs 7.10 at least)
-> 8.4.4  (needs 8.0 at least)   | -> 8.6.5  (needs 8.2  at least)
-> 8.6.5  (needs 8.2 at least)   | -> 8.10.7 (needs 8.6 at least)
-> 8.10.7 (needs 8.6 at least)   | -> 9.2.5  (needs 8.10 at least)
-> 9.2.5  (needs 8.10 at least)

Well, one version would be win when using 7.10.3 (modulo inaccurate
information on Haskell website :-)).


All in all, I am proposing to send a patch for the first path for this
core-updates cycle and postpone this other path – not doable for this
cycle; I will resume this story later.


Andreas, core-updates is frozen but is the former shorter bootstrap
chain acceptable?


>> I mean I propose to have both: ghc-x.y (with tests) and
>> ghc.x.y/bootstrap (without tests), it would ease the maintenance of the
>> Haskell ecosystem on several architectures.  WDYT?
>
> I have a bad feeling about turning the testsuites of intermediate versions
> off. Yes, they take a long time, but then they also ensure the resulting
> compiler actually works (with high confidence) and we don’t silently
> propagate issues into the next one.

Well, I am convinced that we are doing the optimal way.  For instance,
the run is sequencial,

--8<---------------cut here---------------start------------->8---
       #:test-target "test"
       ;; We get a smaller number of test failures by disabling parallel test
       ;; execution.
       #:parallel-tests? #f
--8<---------------cut here---------------end--------------->8---

Then, for another example, the GHC testsuite is distributed separately,

    https://downloads.haskell.org/~ghc/8.10.7/ghc-8.10.7-src.tar.xz
    https://downloads.haskell.org/~ghc/8.10.7/ghc-8.10.7-testsuite.tar.xz

And Debian seems considering the GHC testsuite as a package,

    https://tracker.debian.org/pkg/ghc-testsuite

Maybe we could do that.  It would allow to catch errors and not wait
ages after each GHC bootstrap toolchain completes all its testsuite.

WDYT?


Cheers,
simon