ghc-options applies to all dependencies, not just local packages

[edsko]

With traditional build, I would use

cabal build --ghc-option=-ddump-simpl

If I try the same with new-build, it starts to rebuild every single dependency; presumably because it considers the compiler flags for all dependencies to have changed. I tried to do

packages: ingest.cabal

profiling: True
executable-profiling: True
constraints: Cabal >= 1.24

program-options
  ghc-options: -fprof-auto 

package ingest
  ghc-options: -ddump-simpl -ddump-to-file

but although it doesn't complain about the ghc-options inside the package section, it doesn't seem to take it into account either; no dump files get created. What is the right approach?

---

edit by @23Skidoo: Currently recommended workaround is to add a cabal.project that enables ghc-options for each package separately:

package foo
  ghc-options: -Werror

package bar
  ghc-options: -Werror

Cabal's own CI uses this approach.

[23Skidoo]

My intuition is that the second option ought to work, so we should fix it if it doesn't. Related: I've long wanted a cabal ghc-core ModuleName command.

[dcoutts]

The prog options should apply only to local packages, not all deps, just as all other command line or config top level options do.

[edsko]

Ah, turns out this is a duplicate of #3891 .

[dcoutts]

With traditional build, I would use

cabal build --ghc-option=-ddump-simpl

If I try the same with new-build, it starts to rebuild every single dependency; presumably because it considers the compiler flags for all dependencies to have changed.

This is still a bug.

[ezyang]

See also #3720

[ezyang]

Bumping priority, this is pretty major and makes top-level ghc-options unusable.

[omefire]

Interesting one. I'd like to take a look and see if I can help fix this.

[ezyang]

Thanks @omefire, much appreciated! programOptionsSectionDescr at cabal-install/Distribution/Client/ProjectConfig/Legacy.hs is a good place to start (then just track how the config gets propagated through the code.)

[ezyang]

Hey @omefire, any progress / anything we can do to help?

[omefire]

@ezyang I've been busy with moving to California and haven't had time to work on it. I'll get back to it by Friday evening or Saturday morning.

[omefire]

I wasn't able to reproduce this bug. Here's what I did:

- git clone https://github.com/jaspervdj/patat.git
- cd patat; cabal new-build
- modify patat.cabal by adding a new entry to the Ghc-options field
- rerun cabal new-build

Instead of rebuilding the package and all its dependencies (aeson, ansi-terminal, etc...), I get a message Up to date.
Is there something I'm missing ?

[ezyang]

Well, the original bug report was referring to ghc-options in cabal.project. What if you put it there?

[omefire]

Ok, I wasn't aware of those two different files. can you point me to any documentation regarding cabal.project or project.cabal files ? and what the differences between them are ?

[harendra-kumar]

@23Skidoo It will be great if this issue can be prioritized. Because of this we cannot use -Werror option at all in CI builds, it tries to build everything with -Werror and many dependencies fail to build. I have been using stack builds with -Werror instead of cabal builds to avoid this issue.

[phadej]

I don't think this is high priority as there is a workaround by explicitly listing the packages

package foo
  ghc-options: -Werror

package bar
  ghc-options: -Werror

e.g. haskell-ci have a way to generate such "local package" options sections for CI's cabal.project.

---

Yet, it might be good idea to go through https://github.com/haskell/cabal/issues?q=is%3Aopen+is%3Aissue+label%3A%22priority%3A+high+%3Afire%3A%22 as there are not so much of those, and some seems to be outdated (by v2-build e.g.)

[phadej]

Note how Cabal own CI uses that workaround: https://github.com/haskell/cabal/blob/5a07388f299ddc55fea5ba61c1b5b74de473c9b9/cabal.project.travis

[chshersh]

@phadej But what if I don't want to introduce a separate file just to build my package on CI with -Werror? I personally don't need cabal.project that often. And, moreover, even if I have one, I probably need to introduce a separate file and duplicate all configurations because I don't want to build with -Werror locally.

[23Skidoo]

IMO if you're using -Werror on CI, it makes sense to use it locally too. You can always disable it temporarily.

[chshersh]

I favour the approach where you use -Wall locally and -Werror on CI. During development, it's a bit tedious to get rid of all warnings every time: redundant imports, missing export lists, unused functions/types/fields/constructors, etc. But your final result shouldn't contain any warnings. Unfortunately, it's quite easy to miss them locally. Fortunately, this is a purpose of CI — catch all such things.

[harendra-kumar]

@phadej thanks for pointing out the workaround. I was not aware of it. This is useful.

[lexi-lambda]

A problem with the current workaround is that it’s impossible to list out all local packages in the global ~/.cabal/config file. I’d like to enable ghc-options: -j for all local packages globally, but I don’t think that’s currently possible.

[cartazio]

What are the architectural or man power blockers here ?

[emilypi]

@lexi-lambda agreed - this would be great for tooling as well, since certain tools like hsinspect require plugins to be enabled in order to gather the correct data. Obviously committing build-tool specific details to source is a bad idea, but without being able to support flags and options with some global config or cabal.project.local-like behavior, I'm left in a suboptimal position.

Just so it doesn't like I'm complaining at developers, I'm available to discuss this more in depth and contribute code towards this. Just point me in the right direction 😄

[sol]

Bumping priority, this is pretty major and makes top-level ghc-options unusable.

@ezyang agree!

I don't think this is high priority as there is a workaround by explicitly listing the packages

@phadej disagree!

@hvr & co, instead of pointing fingers at others, lobbying against other peoples projects and hampering competition, please put your effort into producing working software yourself!

[cartazio]

Or more broadly: what contributor support or user feedback is needed to help correctly triaging and assessing priorities?

…

On Mon, Aug 31, 2020 at 9:17 AM Simon Hengel ***@***.***> wrote: Bumping priority, this is pretty major and makes top-level ghc-options unusable. @ezyang <https://github.com/ezyang> agree! I don't think this is high priority as there is a workaround by explicitly listing the packages @phadej <https://github.com/phadej> disagree! @hvr <https://github.com/hvr> & co, instead of pointing fingers at others, lobbying against other peoples projects and hampering competition, please put your effort in producing working software yourself! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3883 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQXXVMJMA6SETDFCUBLSDOPHFANCNFSM4CQN65FA> .

[jneira]

After #7973, ghc-options is only applied to all local packages. It is still possible recover the old behaviour, see the workaround here: #7973 (comment)
Closing the issue, thanks all!