[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken
From: |
Timothy Sample |
Subject: |
bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken |
Date: |
Tue, 16 Jul 2019 11:08:04 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Hi Robert,
Robert Vollmert <address@hidden> writes:
> ghc-tasty depends via “inputs” on ghc-clock-bootstrap (v0.5) which is built
> without tests,
> while ghc-clock (v0.7) depends via “native-inputs” on ghc-tasty for tests.
>
> This means that any package which depends on ghc-tasty and ghc-clock is
> potentially broken,
> e.g.:
>
> Warning:
> This package indirectly depends on multiple versions of the same package.
> This is very likely to cause a compile failure.
> package tasty (tasty-1.1.0.3-98rSghuW4l26JGzzQLN3ha) requires
> clock-0.5.1-KAiVgaxjUlIIuEB7RoOIe6
> package hspec-core (hspec-core-2.5.5-BSfG8Pnx1al9rTpu1j0PaW) requires
> clock-0.7.2-JStwYFlKVmNHl0K1ll1Mx5
>
> I’d suggest breaking the cycle instead by
>
> 1. introducing tasty-bootstrap which builds against the `time` module via the
> cabal flags:
>
> flag clock
> description:
> Depend on the clock package for more accurate time measurement
> default: True
>
> This could be done via
> (arguments `(#:configure-flags (“—flag=-clock”)))
> as far as I understand.
>
> 2. changing ghc-clock to test via tasty-bootstrap (and possibly some more
> variant testing
> packages that would be changed to depend on tasty-bootstrap)
>
> 3. changing tasty to test via ghc-clock.
>
>
> (I gave this approach a shot myself, but I’m running into mysterious silently
> hanging guild and guix build
> processes — possibly some cyclic dependencies which are noticed?)
After looking at this and your patch at <https://bugs.gnu.org/36249>,
I’m wondering if it works as long as we make sure the versions match.
Can we just inherit the current “ghc-clock”, disable its tests, and call
it “ghc-clock-bootstrap”? Is the Cabal consistency checking too clever
for that?
If that doesn’t work, can you explain why the method you proposed above
doesn‘t work? It seems a little simpler than your patch. In fact,
maybe we could live with the main “ghc-tasty” package being built
without “ghc-clock” (via the flag you mentioned).
Sorry for taking so long to get to this, BTW. :(
-- Tim
- bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken,
Timothy Sample <=