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

Package sections in cabal.project are insufficient, need local section #3579

Open
ezyang opened this Issue Jul 21, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@ezyang
Contributor

ezyang commented Jul 21, 2016

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

This comment has been minimized.

Member

dcoutts commented Jul 26, 2016

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

This comment has been minimized.

Contributor

ezyang commented Aug 7, 2016

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

@ezyang ezyang referenced this issue Aug 24, 2016

Open

Tracking bug for cabal.project semantics #3720

1 of 8 tasks complete
@ezyang

This comment has been minimized.

Contributor

ezyang commented Sep 3, 2016

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

This comment has been minimized.

Member

dcoutts commented Sep 8, 2016

@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

This comment has been minimized.

Contributor

ezyang commented Sep 8, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment