Repository navigation
Haddock incompatibility with older GHC #383
Description
Activity
This might be the same issue as haskell/haddock#836, in which case it seems like there might not be much of a fix beyond hiding the docs behind an
#if MIN_VERSION_base(4,12,0)and providing an#elsewithout the additional Haddock.CPPis already enabled for that module, so at least it won't be adding system complexity as well as the redundant code.Question is: do we really need to support old buggy versions of
haddock? What does it buy us?I think it is possible to use newer haddock version with older ghc, so if someone really needs to build documentation with ghc-8.4 and older they should be able to figure it out. Or maybe am I missing something?
@ag-eitilt you can put a constraint in a global cabal config. Or skip running haddock for old GHCs. Hackage Matrix does not run it, so why would you?
I don’t think this qualifies as an issue on vector side in 2021.
Reacted by Alexey KuleshevichMakes sense, though I'm not completely in support of only partially dropping support like that, given how tightly-coupled GHC and Haddock are; I will admit that there's no great way to make it more explicit, however, when we can't even directly specify what compilers are supported. By the way, I played with things a bit, and you can not, in fact, use different versions of each:
> cd vector-0.12.2.0 > cabal haddock --with-compiler ghc-8.4.4 --with-haddock haddock-ghc-8.10.4 Build profile: -w ghc-8.4.4 -O1 In order, the following will be built (use -v for more details): - vector-0.12.2.0 (lib) (configuration changed) Configuring library for vector-0.12.2.0.. cabal: Haddock's internal GHC version must match the configured GHC version. The GHC version is 8.4.4 but haddock is using GHC version 8.10.4 cabal: Failed to build documentation for vector-0.12.2.0.So, therefore, versions 0.12.2.0 and 0.12.3.0 only support GHC <= 8.4.4 so long as the docs aren't being built. It is still a valid line to draw, but I have to admit to being a bit disappointed that core tools in the Haskell ecosystem are considered "old buggy versions" before they're even three years old. For reference, stable Debian looks to be installing 8.4.4 even now, and the LTS release is still using 8.0.1 (I'm generating Haddock in solidarity with anyone using those older versions).
@Bodigrim I'd love to; where would I put that constraint? Like I said originally,
cabal.projectdoesn't work. I could add a--config-fileargument, switching on the desired version, to the script I use for running older GHC, but as I understand it, that would overwrite everything else I have set in my main config file.For comparison, my entire (now tested) proposed fix is six lines of code (plus, depending on how quickly the next version is set to come out, one for 0.12.3.0 as well), and deprecating the *.0 versions so cabal-install doesn't pull them in. I can't create a PR because Github doesn't allow them for tags, but I'm sure it would be easy enough to copy over the patch.
core tools in the Haskell ecosystem are considered "old buggy versions" before they're even three years old
Thing is they are buggy and unsupported. Same is true for GHC by the way. Only way to get bugfixes is to upgrade. And I don't think that it's very important to maintain haddock buildable by old GHCs since it's possible
I could add a --config-file argument, switching on the desired version, to the script I use for running older GHC, but as I understand it, that would overwrite everything else I have set in my main config file.
AFAIU it should read from config file supplied on the command line instead of default one, not overwriting anything.
proposed fix is six lines of code
Problem is uses CPP in a way that different compilers may use different versions of data type definition.
The discussion around haskell/cabal#5232 implies that this might wind up being an issue with Cabal rather than with GHC/Haddock itself. I'll stop pushing this here quite as aggressively, though I will admit to being rather disappointed if the documentation is not considered worth a simple fix.
core tools in the Haskell ecosystem are considered "old buggy versions" before they're even three years old
Thing is they are buggy and unsupported. Same is true for GHC by the way. Only way to get bugfixes is to upgrade. And I don't think that it's very important to maintain haddock buildable by old GHCs since it's possible
I'm not disputing that it's outdated, I'm just bemoaning the perception of short shelf life that has developed in the ecosystem. Though I will again point to Debian where any more conservative users (i.e. larger corporations) are still using those older versions, and that, according to its
baseconstraints,vectornominally supports GHC all the way back to 7.4.1. My argument through all this is that, if that support range is truly the case, breaking Haddock like this effectively drops support for what's packaged with seven major versions of GHC for very little gain; I've only personally verified back to 7.10.3, but that's still at least four broken versions.I could add a --config-file argument, switching on the desired version, to the script I use for running older GHC, but as I understand it, that would overwrite everything else I have set in my main config file.
AFAIU it should read from config file supplied on the command line instead of default one, not overwriting anything.
That was a bit ambiguous on my end; I meant the same thing by "overwrite" as you do by "instead of". I consider having to duplicate every other bit of my config an unacceptable cost.
proposed fix is six lines of code
Problem is uses CPP in a way that different compilers may use different versions of data type definition.
It uses CPP to add Haddock and nothing else. The definition itself is exactly the same. Any build system which doesn't add the
MIN_VERSIONmacros will be compiled to exactly the same code, and just miss a small bit of documentation. Any compiler which can't understand CPP will fail on the#include "vector.h"line a bit farther up.Well, that's an interesting find, and much better than the CPP! I'll keep records in mind for potential Haddock issues going forward in my own code. Thanks for the fix!
Reacted by Alexey Kuleshevich@ag-eitilt Yeah, I try to avoid CPP when possible and I thought today to try and see if record syntax can do the trick and it did ;) So, I'll make a vector-0.12.3.1 but I think that will be the last vector-0.12.x version, because after that the next release will be 0.13
@lehins: Would it be possible to release this fix soonish?
I got hit by this by putting
documentation: Truein my.cabal/configand then trying to build one of my packages with an old GHC:tasty-silver$ cabal test -w ghc-7.8.4 ... Data/Vector/Mutable.hs:80:28: parse error on input ‘{-# UNPACK’ Warning: Failed to build documentation for vector-0.12.3.0 (which is required by test:test from tasty-silver-3.3).@andreasabel note that support for GHC 7.8 (and in general GHC < 8.0) has been dropped, so if you want to use GHC 7.8, a release with the fix won't help you.
@andreasabel note that support for GHC 7.8 (and in general GHC < 8.0) has been dropped, so if you want to use GHC 7.8, a release with the fix won't help you.
Thanks for the heads up, @konsumlamm! The fix would help with GHC >= 8.0, which has the same problem:
$ cabal test Resolving dependencies... Build profile: -w ghc-8.0.2 -O1 In order, the following will be built (use -v for more details): ... - vector-0.12.3.0 (lib) (requires build) ... ... Data/Vector/Mutable.hs:80:28: error: parse error on input ‘{-# UNPACK’ Warning: Failed to build documentation for vector-0.12.3.0 (which is required by test:test from tasty-silver-3.3).@andreasabel No problem, I'll make a
0.12.3.1later on today.Reacted by Andreas Abel- Reacted by Andreas Abel
I like to locally test my packages against every version the Hackage matrix would be testing, just to have the most accurate data before actually releasing, and several times have run into issues with
vectorby the time I get back to GHC-8.4.4 -- namely, the Haddock fails to build. Since that's not marked in thevector.cabal(and sincecabal.projectfiles don't supportif()), I need to manually add a--constraint=vector<0.12.2every time I try to test an older GHC, which I never remember to do until after flailing around for a bit. The matrix (and presumably most users) don't have this issue because everything works fine if the Haddock is never built, but I have my global Cabal config set to build the docs for everything.The issue seems to be with the
{-# UNPACK #-}pragmas onData.Vector.Mutable.MVector, and their interaction with the postfix Haddock; there might be other similar issues, but that's the first error the build hits. It's too late at night for me to pick it apart at the moment, butvector-0.12.2.0added (admittedly needed) explanation of each argument to the constructor in a way which the older Haddock doesn't seem to be able to parse. I'll look into this a bit further soon, but I just wanted to put this out there before I lost track of it again, and in case anyone else knows the fix off the top of their head.