ghcide: Add flags to toggle building each executable

[hololeap]

This package is a transient dependency of haskell-language-server.
However, only the library is needed. These three flags give the option for
those who do not need the executables to disable them.

executable:

• Toggles the ghcide executable
• enabled by default.

test-exe:

• Toggles the ghcide-test-preprocessor executable
• disabled by default

bench-exe:

• Toggles the ghcide-bench executable
• disabled by default

[pepeiborra]

I'm not supportive of this change as it is:

• The test-exe flag default value breaks cabal test ghcide
• The bench-exe flag default value breaks cabal bench ghcide

I understand that you are coming at this from "why do I have to build all these executables if all I want is HLS", however I would only be supportive of a change that solves that problem if it has no negative impact on the ghcide development workflow.

[hololeap]

I changed it so that all three flags have default: True in hopes this will not break the workflow. This seems like a good compromise to me since building the exe's can still be disabled from the command line.

[pepeiborra]

Thanks!

[michaelpj]

I'm slightly missing the motivation. HLS doesn't depend on these, so if you're just building HLS then cabal won't build them. Is it so that you can run cabal build all and not have to build them?

[jneira]

I'm slightly missing the motivation. HLS doesn't depend on these, so if you're just building HLS then cabal won't build them. Is it so that you can run cabal build all and not have to build them?

hmm cabal builds executable components by default i think

[hololeap]

@michaelpj @jneira Yes, cabal builds all executable components unless you create a mechanism like this to turn them off. I run into this when packaging for Gentoo, which strives to give the end user as much control over their packages as possible (and currently uses cabal under the hood). Without this patch I would have to either:

1. Give the user no control over whether the executables are installed, even if they don't want them
2. Maintain a patch for the ghcide.cabal file for every new release.

(Just so you know what my personal motivations are.)

[michaelpj]

Yes, cabal builds all executable components unless you create a mechanism like this to turn them off.

Well, perhaps the question becomes: how are you invoking cabal?

If you build the executable component for haskell-language-server it doesn't build the ghcide executables.

> cabal build exe:haskell-language-server
...
> vim ghcide/exe/Main.hs # make trivial edit
> cabal build exe:haskell-language-server
Up to date

[hololeap]

@michaelpj The way we have been doing it is to convert each .cabal package into a Gentoo package, where the dependency graph is handled solely by our package manager. We then compile Setup.hs and invoke setup for the configure, build, test, etc. phases on each package individually, and install them to a global location. So each package is built in relative isolation and there is no current integration of the v2 cabal features.