Catch up with cabal modifications on hackage

[domenkozar]

See http://hackage.haskell.org/package/happy-1.19.5/revisions/

Stil couldn't get it to build with:

$ stack init
$ stack build --nix
mtl-2.2.1: configure
mtl-2.2.1: build
mtl-2.2.1: copy/register
happy-1.19.6: configure (exe)
[1 of 2] Compiling Main             ( /home/ielectric/dev/happy/Setup.lhs, /home/ielectric/dev/happy/.stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/setup/Main.o )
[2 of 2] Compiling StackSetupShim   ( /home/ielectric/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /home/ielectric/dev/happy/.stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/setup/StackSetupShim.o )
Linking /home/ielectric/dev/happy/.stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/setup/setup ...
Configuring happy-1.19.6...
happy-1.19.6: build (exe)
Preprocessing executable 'happy' for happy-1.19.6...
setup: The program 'happy' is required but it could not be found
Completed 2 action(s).

--  While building package happy-1.19.6 using:
      /home/ielectric/dev/happy/.stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/setup/setup --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0 build exe:happy --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

[domenkozar]

@simonmar this one is a pain due to commercialhaskell/stack#3151 (comment) and would need another bugfix release.

[domenkozar]

@simonmar any feedback?

[erikd]

This looks ok to me. Is this correct @hvr ?

[hvr]

Yeah, the problem @domenkozar still encounters is the very issue why there's a more fundamental problem with happy beyond its use of custom-setup. While old-cabal supported this magic special case of a cyclic dependency happy needs happy to build, with new-build this simply won't work anymore in future, as cabal is now in charge to solve and automatically install build-tool dependency version constraints (both lower & upper bounds! fortunately this doesn't result in dependency hell as cabal's killer feature qualified goals is used for build-tools; so a single build-plan can require several different versions of happy or alex without running into a version constraint conflict!). As it stands now, happy is currently a "broken" package in that respect, as it requires the build-tool happy without declaring it in the .cabal specification (thereby violating the "no untracked dependencies" mantra underlying CABAL's design). What I'm trying to say is that happy should try to get rid of the self-cyclic dependency and perform the bootstrapping outside of cabal build; while at it, ideally happy would become a build-type:simple package.

[erikd]

Oh dear, correcting this sounds like quite a yak shave.

[domenkozar]

Adding the following to the stack.yaml helps resolve the issue:

nix:
  packages: [haskellPackages.happy]

[snoyberg]

For the record, if I have a happy executable available on my PATH, building works with Stack, cabal, and cabal new-build. I'm not sure how to trigger the behavior that @hvr describes.

[domenkozar]

@simonmar so all being said, it would be really useful to have this merged and released to hackage.

[simonmar]

If installing Happy requires Happy, it's a bug. (similarly for Alex). Happy is not supposed to require bootstrapping because we ship the pre-generated .hs files with the package, but that has always been very fragile and there are at least a couple of open tickets against cabal for bugs in this behaviour. But I do always check when I release Happy and Alex that this still works.

That said, I have little clue about the issues being raised here and I'm a bit short on capacity to fully understand everything, so I'm happy to click green buttons if people are sure that this is the right way forwards and won't break any existing functionality.

[nh2]

From @domenkozar and @snoyberg's comment, it sounds like the proposed added setup-depends are sufficient as long as happy is in the PATH.

@hvr @erikd Can you confirm that it works for you too?

Then we could ask @simonmar to merge.

[deepfire]

What helped in my case was:

rm -f src/AttrGrammarParser.ly src/Parser.ly tests/ParGF.yg

The build with GHC 8.4.1-alpha1 succeeded thereafter..