[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#36084: closed (ghc-tasty/ghc-clock circular depend

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#36084: closed (ghc-tasty/ghc-clock circular dependency breaking is broken)
Date: Tue, 16 Jul 2019 19:12:01 +0000

Your message dated Tue, 16 Jul 2019 15:11:00 -0400
with message-id <address@hidden>
and subject line Re: bug#36084: ghc-tasty/ghc-clock circular dependency 
breaking is broken
has caused the debbugs.gnu.org bug report #36084,
regarding ghc-tasty/ghc-clock circular dependency breaking is broken
to be marked as done.

(If you believe you have received this mail in error, please contact

36084: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36084
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: ghc-tasty/ghc-clock circular dependency breaking is broken Date: Tue, 4 Jun 2019 02:26:04 +0200
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,

    This package indirectly depends on multiple versions of the same package. 
This is very likely to cause a compile failure.
      package tasty (tasty- requires 
      package hspec-core (hspec-core-2.5.5-BSfG8Pnx1al9rTpu1j0PaW) requires 

I’d suggest breaking the cycle instead by

1. introducing tasty-bootstrap which builds against the `time` module via the 
cabal flags:

flag clock
    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?)

--- End Message ---
--- Begin Message --- Subject: Re: bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken Date: Tue, 16 Jul 2019 15:11:00 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Robert Vollmert <address@hidden> writes:

>> On 16. Jul 2019, at 17:08, Timothy Sample <address@hidden> wrote:
>> Hi Robert,
>> 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).
> I tried the direct approach again, and this time it worked. Posted an
> updated patch.
> I believe this should be fine, since GHCs builds should be deterministic.

It looks like this is a common idiom for us, so I’m pretty confident,
too.  Fixed in 71e5d425c9b9e108ebdd06d13de45b56dddd9ef5.  Thanks!

-- Tim

--- End Message ---

reply via email to

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