Hi Robert, Robert Vollmert <r...@vllmrt.net> 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
