RyanGlScott
commented
5 years ago If you're wondering why I'm running cabal-install without having Haddock on my PATH, it's because that's the setup used by haskell-ci.
Open RyanGlScott opened 5 years ago
RyanGlScott
commented
5 years ago If you're wondering why I'm running cabal-install without having Haddock on my PATH, it's because that's the setup used by haskell-ci.
phadej
commented
5 years ago This is weird. As on my machine using HVR PPA builds:
% ls /opt/ghc/7.10.3/bin
ghc ghc-7.10.3 ghci ghci-7.10.3 ghc-pkg ghc-pkg-7.10.3 haddock haddock-ghc-7.10.3 hp2ps hpc hsc2hs runghc runghc-7.10.3 runhaskell
% ls /opt/ghc/8.0.2/bin
ghc ghc-8.0.2 ghci ghci-8.0.2 ghc-pkg ghc-pkg-8.0.2 haddock haddock-ghc-8.0.2 hp2ps hpc hsc2hs runghc runghc-8.0.2 runhaskell
% ls /opt/ghc/7.0.4/bin
ghc ghc-7.0.4 ghci ghci-7.0.4 ghc-pkg ghc-pkg-7.0.4 haddock haddock-ghc-7.0.4 hp2ps hpc hsc2hs runghc runghc-7.0.4 runhaskelli.e. there are both haddock as haddock-ghc-<ver>, so if cabal-install manages to find haddock for newer/older GHC, why it doesn't find for versions you listed?
RyanGlScott
commented
5 years ago Given that this bug only occurs with build-type: Custom (which means that you may link against an older version of Cabal), I'm starting to wonder if this is an old Cabal bug manifesting itself. As an experiment, I ran cabal new-freeze using each version of GHC from 7.0.4 to 8.8.1, and here are the results:
7.0.4 any.Cabal ==1.10.2.0 || ==1.20.0.4
7.2.2 any.Cabal ==1.12.0 || ==1.22.8.0,
7.4.2 any.Cabal ==1.14.0 || ==2.2.0.1
7.6.3 any.Cabal ==1.16.0 || ==3.0.0.0
7.8.4 any.Cabal ==1.18.1.5 || ==3.0.0.0
7.10.3 any.Cabal ==1.22.5.0
8.0.2 any.Cabal ==1.24.2.0
8.2.2 any.Cabal ==2.0.1.0
8.4.4 any.Cabal ==2.2.0.1
8.6.5 any.Cabal ==2.4.0.1
8.8.1 any.Cabal ==3.0.0.0I'm not quite sure what || means in a cabal.project.freeze file, but I'll assume that the later Cabal version is the one that is linked against in the custom Setup script. If that is the case, then one thing becomes clear: GHC 7.0.2, 7.2.2, and 7.10.3 all link against Cabal-1.22.5.0 or earlier, while every other version of GHC links against a later version of Cabal.
My conjecture is that there was an old bug in the way Cabal handled haddock that was fixed in 1.24. As evidence for this claim, I compiled cabal-install-1.22.5.0 and tried running cabal v1-haddock without haddock on my PATH. Sure enough, I got the same error:
$ /home/rgscott/Documents/Hacking/Haskell/cabal/dist-newstyle/build/x86_64-linux/ghc-7.10.3/cabal-install-1.22.5.0/x/cabal/build/cabal/cabal haddock --with-ghc /opt/ghc/8.8.1/bin/ghc
Warning: /home/rgscott/.cabal/config: Unrecognized field overwrite-policy on
line 99
/home/rgscott/.cabal/config: Unrecognized field installdir on line 98
/home/rgscott/.cabal/config: Unrecognized stanza on line 16
Warning: cabal-sandbox.cabal: Ignoring unknown section type: custom-setup
Running Haddock for cabal-sandbox-0.1.0.0...
cabal: The program 'haddock' version >=2.0 is required but it could not be
found.(This happens for every version of GHC, not just 7.0.4/7.2.2/7.10.3.)
RyanGlScott
commented
5 years ago As a side note, it's not clear to me why some old versions of GHC link their Custom setup scripts against recent Cabals and why others link against old Cabals. Is there a way to make it so that the most recent version of Cabal is always picked? I tried using -w /opt/ghc/7.10.3/bin/ghc --constraint=Cabal==3.*, but that didn't seem to help.
phadej
commented
5 years ago @RyanGlScott constraint=any.Cabal==3.*. Not any doesn't constraint setup dependencies.
There's an implicit Cabal lower-bound that cabal-install uses https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/ProjectPlanning.hs#L1059-L1090
So even Cabal-1.10 is allowed, cabal-install doesn't (want to) know how to talk to those.
RyanGlScott
commented
5 years ago Ah, I didn't realize that --constraint="Cabal==3.*" doesn't apply to Setup dependencies. Indeed, cabal new-haddock -w /opt/ghc/7.10.3/bin/ghc --constraint="any.Cabal==3.*" is another way to work around the issue.
Now that it seems pretty clear that this is the result of an old Cabal bug, is there anything that can be done to fix this in the latest Cabal? It's not clear to me what parts of custom Setup scripts are handled by the old Cabal version and which parts are handled by the new Cabal version.
phadej
commented
5 years ago @RyanGlScott
cabal-install calls (old when Custom: Cabal-1.x) ./Setup./Setup calls haddockI don't see anything in Cabal`` changelog around1.24relating tohaddockexcept supporting response files. That shouldn't affect--with-haddockflag passing fromcabal-installtoSetup`. Maybe it does.
Tracing from CmdHaddock.hs is the start.
With GHC-8.4.4 I see
/opt/ghc/bin/haddock-ghc-8.4.4 '@/home/ogre/mess/lca-0.3.1/dist-newstyle/build/x86_64-linux/ghc-8.4.4/lca-0.3.1/doc/html/lca/haddock-response10409-1.txt'With GHC-7.0.4
/home/ogre/.cabal/bin/haddock --ghc-version
setup: Haddock's internal GHC version must match the configured GHC version.I.e.when discovering of haddock is left to the Setup script, old Cabal does poor job. That's why --with-haddock workaround works, even for old GHCs, as it's passed to setup configure.
This can be fixed on cabal-install level by always passing --with-haddock, in the same way as we always pass --with-ghc-pkg, e.g. in
/home/ogre/mess/lca-0.3.1/dist-newstyle/build/x86_64-linux/ghc-7.0.4/lca-0.3.1/setup/setup configure --verbose=2 --builddir=/home/ogre/mess/lca-0.3.1/dist-newstyle/build/x86_64-linux/ghc-7.0.4/lca-0.3.1 --ghc --prefix=/home/ogre/.cabal --bindir=/home/ogre/.cabal/bin --libdir=/home/ogre/.cabal/lib/x86_64-linux-ghc-7.0.4/lca-0.3.1-inplace --libsubdir= --libexecdir=/home/ogre/.cabal/libexec/x86_64-linux-ghc-7.0.4/lca-0.3.1/ --datadir=/home/ogre/.cabal/share/x86_64-linux-ghc-7.0.4/lca-0.3.1 --datasubdir= --docdir=/home/ogre/.cabal/share/doc/x86_64-linux-ghc-7.0.4/lca-0.3.1 --htmldir=/home/ogre/.cabal/share/doc/x86_64-linux-ghc-7.0.4/lca-0.3.1/html --haddockdir=/home/ogre/.cabal/share/doc/x86_64-linux-ghc-7.0.4/lca-0.3.1/html --sysconfdir=/home/ogre/.cabal/etc --enable-library-vanilla --disable-library-profiling --disable-shared --disable-executable-dynamic --disable-executable-profiling --enable-optimization --disable-library-for-ghci --disable-split-objs --disable-executable-stripping --disable-library-stripping --package-db=clear --package-db=global --package-db=/home/ogre/.cabal/store/ghc-7.0.4/package.db --package-db=/home/ogre/mess/lca-0.3.1/dist-newstyle/packagedb/ghc-7.0.4 --extra-prog-path=/home/ogre/.cabal/bin --dependency=base=base-4.3.1.0-bafbc7ad22c91044397c91929f8c61bc --disable-tests --disable-library-coverage --exact-configuration --disable-benchmarks --with-ghc=/opt/ghc/bin/ghc-7.0.4 --with-ghc-pkg=/opt/ghc/bin/ghc-pkg-7.0.4 --ghc-option=-hide-all-packagesI don't see any drawback in trying to discover haddock program, using heuristic "Use haddock-ghc-<ver> when compiler is ghc-<ver>" (i.e. similar to what we do with ghc-pkg). If it's not there, then do nothing.
phadej
commented
5 years ago Crap, can one make github not add those @RyanGlScott added a commit to ekmett/bytes that referenced this issue 12 minutes ago. Completely unncessary noise here.
Describe the bug Attempting to run
new-haddockon any package that usesbuild-type: Customwill result in an error when:haddockexecutable is not on one'sPATH.To Reproduce First, make sure that
haddockis not on yourPATH:Next, grab your favorite package that uses
build-type: Custom. I preferlca, as it has very minimal dependencies:Now run
new-haddock:Expected behavior I would expect the Haddocks to build, like they do when I use GHC 8.8.1 instead:
System informataion
Additional context Note that this problem "did not happen" on
cabal-install-2.4because the error code was swallowed (due to #5977).