You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
output the flags that are passed to ghc into a .ghc.flags file in the root of every source directory
output the PATH that is used to invoke ghc into a .ghc.path file in the root of every source directory
Downstream tools can then make use of these flags to invoke the ghc api correctly... it provides flags relevant for package loading, language extensions, CPP, and more. Contrast to .env files, which only achieve the package loading aspect and are not enough in most real world cases.
An alternatives to this approach was taken in hie-bios which effectively amounts to tricking the build tool into running a faux ghci and extracting the flags that way but has many downsides as described in #6203 (I reimplemented the hie-bios approach in a shell script to highlight what tooling authors are being forced to do).
However, installation of a compiler plugin is very cumbersome for users due to #6307 and therefore the hie-bios authors continue to use the approach outlined above, plus it doesn't work for older ghcs that do not support plugins.
If cabal were to support a user option to output the .ghc.flags / .ghc.path files in the same manner as the ghcflags plugin as then it would make sense to add support for these files in hie-bios and then all tooling that needs access to the ghc flags would benefit. This would be a competitive advantage for cabal over stack as it would make user-facing tools such as HIE "just work" in more cases.
Hi, as far i can understand from the discussion in #6203show-build-info will give us the flags that cabal is going to use in the next build, but you want the flags used in the last build. Main motivation is performance but:
performance is bad enough to implement both features?
tools will need the new flags that are gonna to be used and no the last ones in some cases
or trigger a build only to get them if something in the whole env can change the flags (to know what exactly can trigger it could be tricky: .cabal, cabal.project, global config, env vars, etc etc)
the feature could be added in ghc itself, under a flag, right? Taking the actual plugin as starting point
it would expose the feature for all build systems, not only cabal and stack but bazel, hadrian, nix, etc, etc
I have written a compiler plugin http://hackage.haskell.org/package/ghcflags that does the following on compile:
ghc
into a.ghc.flags
file in the root of every source directoryghc
into a.ghc.path
file in the root of every source directoryDownstream tools can then make use of these flags to invoke the
ghc
api correctly... it provides flags relevant for package loading, language extensions, CPP, and more. Contrast to.env
files, which only achieve the package loading aspect and are not enough in most real world cases.An alternatives to this approach was taken in
hie-bios
which effectively amounts to tricking the build tool into running a fauxghci
and extracting the flags that way but has many downsides as described in #6203 (I reimplemented thehie-bios
approach in a shell script to highlight what tooling authors are being forced to do).However, installation of a compiler plugin is very cumbersome for users due to #6307 and therefore the
hie-bios
authors continue to use the approach outlined above, plus it doesn't work for older ghcs that do not support plugins.If cabal were to support a user option to output the
.ghc.flags
/.ghc.path
files in the same manner as theghcflags
plugin as then it would make sense to add support for these files inhie-bios
and then all tooling that needs access to the ghc flags would benefit. This would be a competitive advantage forcabal
overstack
as it would make user-facing tools such as HIE "just work" in more cases.This supercedes #6203
The text was updated successfully, but these errors were encountered: