Alternative flag logic

[shayne-fletcher]

Have two flags auto and no-ghc-lib. Default behavior exactly as hlint linking ghc-lib-parser-8.10* if not on ghc-8.10 and ghc-8.10* otherwise.

[nh2]

Hey, we're having some trouble building this package in nixpkgs, related to this flag logic:

NixOS/nixpkgs#85178 (comment)

We're using 8.8.5.8 there. Would this PR fix that issue? Should it be backported, or should we use some override (or always give the flag) to best handle it? What is your recommendation?

[shayne-fletcher]

Hi @nh2 ,

Hey, we're having some trouble building this package in nixpkgs, related to this flag logic:

NixOS/nixpkgs#85178 (comment)

We're using 8.8.5.8 there. Would this PR fix that issue? Should it be backported, or should we use some override (or always give the flag) to best handle it? What is your recommendation?

I looked at 8.8.5.8. The way it works is, if the Cabal flag ghc-lib is not set, then, if building with a ghc-8.8.* compiler, ghc-lib-parser-ex will link against the native GHC libraries and not ghc-lib-parser. If building with a non ghc-8.8.* compiler (8.6.5) say, ghc-lib-parser-ex will link with ghc-lib-parser. If the ghc-lib flag is set, ghc-lib-parser-ex is forced to depend on ghc-lib-parser regardless of the building GHC compiler version.

The intent of all this is to speed up build times for programs like hlint if the build compiler version is compatible with the parse tree it's targeting. It's purely an optimization. I would suggest that the simplest thing you can do is simply always define the flag:

cabal new-build --constraint "ghc-lib-parser-ex +ghc-lib"

I suggest for ghc-lib-parser-ex-8.8.5.8 the best choice of ghc-lib-parser to link with would be version 8.8.3.20200412.1.

[nh2]

@shayne-fletcher Thanks for your explanation!

It makes sense to me.

By the way, I think the reason ghc-lib-parser-ex determines that it has no dependency on ghc-lib-parser is that the creation of the hackage-packages.nix file is done with GHC 8.8 (there currently exists only 1 such file in nixpkgs for maintainability/contributer-time reasons, so a specific GHC version needs to be picked), and then later I override the compiler to whatever version the user desires (e.g. 8.6.5).

So that sounds like enabling the flag is exactly what I need to do.

One remaining question though: In

ghc-lib-parser-ex/ghc-lib-parser-ex.cabal

Line 58 in 5087bde

if flag(auto) && impl(ghc >= 8.10.0) && impl(ghc < 8.11.0)

you have a version limit impl(ghc < 8.11.0). Is this just to explicitly whitelist GHC versions, or is it known that some newer GHC version gets rid of the builtin parser again?

Knowing that would help me figure based on what conditional I should enable the flag.

[shayne-fletcher]

So, versions of ghc-lib-parser-ex that contain this line in the build-depends field are saying that if the flag auto is enabled (either by not being explicitly defined - it is True by default or defined and set to True) and the building compiler is of version 8.10.* then link the native GHC libraries (there has been no GHC 8.11 series compiler released today - 8.10.1 is the most recently released GHC compiler). Otherwise, if it is disabled (defined and set to False), then look to the flag no-ghc-lib (False by default) and if not enabled, link with ghc-lib-parser. Thus, to always link with ghc-lib-parser in these newer versions of ghc-lib-parser-ex, the Cabal command

 cabal new-build --constraint "ghc-lib-parser-ex -auto -no-ghc-lib"

or respecting the default of no-ghc-lib,

cabal new-build --constraint "ghc-lib-parser-ex -auto"

will have the effect you want. For these versions of ghc-lib-parser-ex if linking ghc-lib-parser it's probably best to choose a version in the 8.10 series e.g. 8.10.1.20200412 (but not critical, any ghc-lib-parser of any version will work).