[Top][All Lists]

[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- 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]