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).

[philderbeast]

Putting ghc-options in one shared ghc-options.dhall (or defaults.dhall) imported by a package.dhall that hpack-dhall reads to generate a *.cabal could be used to workaround this cabal.project limitation @coot.

[coot]

Thanks @philderbeast that's indeed helpful for some projects, for others (large ones) introducing another layer of tooling is problematic.

[goldfirere]

Bump: just hit this missing feature, too.

[gbaz]

I believe the above linked pr (#7973) resolves this?

[goldfirere]

It looks like it does -- thank you! Then should this ticket be closed?

[jneira]

It should be closed, yeah. After #7973, ghc-options is only applied to all local packages. IT is possible recover the old behaviour, see the workaround here: #7973 (comment)
Thanks!

the cabal.project syntax to apply ghc-options to all local packages would be:

program-options
    ghc-options: -Werror