Skip to content
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

Make 'buildopts' command emit inline-friendly GHC options #52

Open
jtdaugherty opened this issue Mar 12, 2012 · 0 comments
Open

Make 'buildopts' command emit inline-friendly GHC options #52

jtdaugherty opened this issue Mar 12, 2012 · 0 comments

Comments

@jtdaugherty
Copy link
Contributor

What appears to be happening is that git-annex is using a ghc (through a Makefile) to build some haskell files. I don't know how common this is, but it seems like cabal-dev cannot handle this case easily.

cabal-dev provides a command called 'buildopts' that could do what you want without having to add an extra 'ghc' command, but it turns out that 'buildopts' isn't as useful as it could be because its output cannot be directly embedded in a GHC command like:

ghc `cabal-dev buildopts` Foo.hs

This is due to several reasons:

  • it emits informative lines like == GHC Arguments: Start ==;
  • it emits the actual names of the files that cabal-dev would compile if it built your package;
  • it emits all of the GHC options repeatedly for all of the things it would compile if it built your package.

I've never had occasion to use 'buildopts' in its current form, but I can see it being useful if it were possible to construct GHC commands such as the one you are trying to run. I could see people writing some shell commands to munge the output of the current command to get into a form for this purpose, but I could also see everyone having to write those same commands and I'd rather avoid that.

What do folks think about changing 'buildopts' to 1) only emit the options necessary to give GHC the right context, 2) only emit them once, and 3) suppress the informative lines? Is this feasible?

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

No branches or pull requests

1 participant