Skip to content

user option to dump out ghc flags and PATH on compile #7055

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tseenshe opened this issue Sep 11, 2020 · 1 comment
Open

user option to dump out ghc flags and PATH on compile #7055

tseenshe opened this issue Sep 11, 2020 · 1 comment

Comments

@tseenshe
Copy link
Contributor

tseenshe commented Sep 11, 2020

I have written a compiler plugin http://hackage.haskell.org/package/ghcflags that does the following on compile:

  1. output the flags that are passed to ghc into a .ghc.flags file in the root of every source directory
  2. 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.

This supercedes #6203

@jneira
Copy link
Member

jneira commented Sep 11, 2020

Hi, as far i can understand from the discussion in #6203 show-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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants