--- 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,
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?)
--- 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) |
Hi,
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 ---