building cassava with text-short-0.1.3 breaks
recursion-ninja opened this issue · 6 comments
I tried to build our program which depends on cassava
and text-short >= 0.1.3
. I don't understand why it fails to build. I got this error:
$ cabal new-build --with-compiler=ghc-8.6.5
...
...
...
Configuring library for cassava-0.5.1.0..
Preprocessing library for cassava-0.5.1.0..
Building library for cassava-0.5.1.0..
Data/Csv/Conversion.hs:26:3: error:
error: #error **INVARIANT BROKEN** Detected invalid combination of `text-short` and `bytestring` versions. Please verify the `pre-bytestring-0.10-4` flag-logic in the .cabal file wasn't elided.
# error **INVARIANT BROKEN** Detected invalid combination of `text-short` and `bytestring` versions. Please verify the `pre-bytestring-0.10-4` flag-logic in the .cabal file wasn't elided.
^~~~~
|
26 | # error **INVARIANT BROKEN** Detected invalid combination of `text-short` and `bytestring` versions. Please verify the `pre-bytestring-0.10-4` flag-logic in the .cabal file wasn't elided.
| ^
Data/Csv/Conversion.hs:99:0: error:
warning: "MIN_VERSION_text_short" is not defined, evaluates to 0 [-Wundef]
#if MIN_VERSION_text_short(0,1,0)
|
99 | #if MIN_VERSION_text_short(0,1,0)
| ^
Data/Csv/Conversion.hs:99:0: error:
error: missing binary operator before token "("
|
99 | #if MIN_VERSION_text_short(0,1,0)
| ^
Data/Csv/Conversion.hs:1010:0: error:
warning: "MIN_VERSION_text_short" is not defined, evaluates to 0 [-Wundef]
#if MIN_VERSION_text_short(0,1,0)
|
1010 | #if MIN_VERSION_text_short(0,1,0)
| ^
Data/Csv/Conversion.hs:1010:0: error:
error: missing binary operator before token "("
|
1010 | #if MIN_VERSION_text_short(0,1,0)
| ^
`gcc' failed in phase `C pre-processor'. (Exit code: 1)
Failed to build perfect-vector-shuffle-0.1.1. The failure occurred during the
final install step.
It looks similar to #154 . It mentions new versions of cabal
with ^>=
will resolve the need for the CPP nonsense. Have we crossed that threshhold yet? How do I build our code with text-short >= 0.1.3
?
I think I'm hitting the same (or at least a very similar) issue. If you build cassava-0.5.1.0
with --allow-newer=bytestring
(which is what haskell-ci
does when building things with head.hackage
), then Cabal
will pick a build plan that enables the bytestring--LT-0_10_4
flag. But if you look at how it's used in cassava.cabal
:
Lines 109 to 114 in 341963b
Enabling bytestring--LT-0_10_4
only makes sense when you're using an old version of bytestring
. For whatever reason, passing --allow-newer=bytestring
seems to make Cabal
's constraint solver ignore what version of bytestring
you're using (which, in the case of recent GHCs, is much newer than bytestring-0.10.4
). I'm not sure if this is a Cabal
constraint solver bug or not, but one thing is clear: passing --allow-newer=bytestring
inevitably causes +bytestring--LT-0_10_4
to be chosen, which leads to the **INVARIANT BROKEN**
error reported above.
It seems like a simple solution to this problem would be to make bytestring--LT-0_10_4
disabled by default (i.e., add default: False
to its stanza in cassava.cabal
). Since +bytestring--LT-0_10_4
only makes sense for older versions of bytestring
, this seems like the less common code path anyways.
Indeed, it looks like adding default: False
was exactly the workaround implemented in hvr/head.hackage@7107ad3. Is there any reason not to adopt a similar fix upstream?
This is currently preventing our entire project from building and additionally preventing us from benchmarking our project as criterion
depends on cassava
.
Can we make fixing this high priority?
Can a proper fix of this defect be released? Still breaking our entire project from building.
@recursion-ninja unfortunately I couldn't reproduce this; I did the following
git clone https://github.com/amnh/PCG
cd PCG/
cabal v2-build -w ghc-8.6.5
and it succeded without any issue
Some change made (or PR merged) in the last 35 days appears to have resolved the issue.