Cabal: Package sections in cabal.project are insufficient, need local section

[ezyang]

I'm working on a project and I want to turn on -Werror. OK, I'll add ghc-options: -Werror to my cabal.project. BUT WAIT, this turns on -Werror for all my dependencies too. Well, the package I'm building is called Cabal, so I'll put it in a package section package Cabal.

BUT WAIT: setup dependencies caused an older version of Cabal to be built, which also got -Werror applied. Disaster!

All I want is a section that lets me finger the packages that are going to be built inplace.

[dcoutts]

Hmm, I thought options at the top level were for local packages, and the problem was we didn't have any way to have options for all packages. So there may be some mistake here.

Either way, needs fixing and tests on the ProjectConfig -> ElaboratedInstallPlan part would be appropriate here to check the semantics.

[ezyang]

I checked, and at least for cabal-install-1.24 a top-level ghc-options is not understood.

[ezyang]

The reason is that there are a set of options which are only added in the package stanza:

      sectionFields      = legacyPackageConfigFieldDescrs
                        ++ programOptionsFieldDescrs
                             (configProgramArgs . legacyConfigureFlags)
                             (\args pkgconf -> pkgconf {
                                 legacyConfigureFlags = (legacyConfigureFlags pkgconf) {
                                   configProgramArgs  = args
                                 }
                               }
                             )
                        ++ liftFields
                             legacyConfigureFlags
                             (\flags pkgconf -> pkgconf {
                                 legacyConfigureFlags = flags
                               }
                             )
                             programLocationsFieldDescrs,

Was there a reason you specifically did it this way? (@dcoutts)

[dcoutts]

@ezyang there's a program-locations section which has the top-level program locations. But perhaps we should abandon that and just allow $PROG-location and $PROG-options at the top level of the file rather that bundling them into a named sub-section. I guess I was thinking it was tidier this way, but it's not essential.

[ezyang]

Is there a functional difference? Doesn't look like it. Would there be any reason not to support both syntaxes?

[phadej]

Bump. Should this be given higher prioritity? Writing

package local-foo
  ghc-options: -Werror

package local-bar
  ghc-options: -Werror

is tiresome.

[coot]

Bump. Should this be given higher prioritity?

That would be appreciated; in iohk we a cabal.packages with a dozen of local packages. Setting common options for them all would be a relief. This would be also appreciated from the point of a ghc-plugin user (adding --ghc-options=-fplugin=.... just in one place). Currently my cabal.project.local file for that repository contains 17 repetitions (each contains ~5 lines, this adds up to 85 lines, instead of 5 or 6).