Print out more information about the effective configuration when you build

[ezyang]

I have a lot of Cabal projects set to all different versions of GHC, and I often forget if I've specified a constraint on GHC in cabal.project.local. In fact, there isn't an easy way to tell what version we're building with at all. It would be nice if new-build printed out some diagnostic info stating basic information in this regard.

Should it output all information that could be in cabal.project.local? No, I think that is too much. I think we should simply output enough information so you can tell which build profile (ala #3343) you are building into. That's probably what users actually care about. So specifically, here's what they want to know:

• What version of GHC are they building with?
• What optimization level are they building with?
• (Eventually) what build profile is "active"
• (Maybe) what architecture we are building for (this is always "obvious" so maybe we don't have to output it.)

So, when I run cabal new-build, I should see something like:

ezyang@sabre:~/Dev/cabal-shake$ cabal new-build -O0 cabal
Build profile:
  with-compiler: ghc-8.0.1
  optimization: False
Resolving dependencies...
In order, the following will be built (use -v for more details):
 - Cabal-1.25.0.0 (lib) (cannot read state cache)
 - hackage-security-0.5.2.2 (lib) (cannot read state cache)
 - cabal-install-1.25.0.0 (exe:cabal) (cannot read state cache)

What you will learn. You'll learn how new-build projects are configured, and the frontend code which drives the overall new-build process.

[alexeyzab]

Hi there! Is this issue still relevant? If so, would any of the maintainers be interested in providing some mentorship/general help on resolving this so that the newcomers and first-time contributors would have an easier time?

I would like to add this as one of the issues for the upcoming Haskell Weekly's Call for Participation section. See discussion in #75.

These are the guidelines we'd like to stick to in the future:

• Ensure that your project has at least one open-source licence. (we've decided to not define the term "open-source" and it is left to your own interpretation).
• Ensure that the issue tracker for your project is publicly accessible.
• Create a new issue in your issue tracker and clearly describe the task. Also mention the difficulty level (easy/medium/hard/tedious), either as a tag/label or somewhere in the title/description.
• If you have specific requirements for contributors (e.g., copyright waiver), it must be mentioned in the description of the task (preferably with a link to CONTRIBUTING.md).

Thank you!

[23Skidoo]

Yes, it's still relevant, and we can help with mentoring.

[hvr]

Minor bikeshedding suggestion to @ezyang's description: please try to use a more compact output; ideally all extra information would fit into a single line.

[ezyang]

Hi @alexeyzab, yes it is! I'd be happy to mentor. I think the other bullet points are handled.

[fgaz]

Is this fixed with #4605?

[23Skidoo]

I'm closing this as fixed; @ezyang - if you think that there is something more to do here, feel free to reopen.

[ezyang]

Nope, I'm very pleased. Thank you @amir!