Skip to content
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 · 7 comments
Open

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

ezyang opened this issue Jul 21, 2016 · 7 comments

Comments

@ezyang
Copy link
Contributor

@ezyang 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
Copy link
Contributor

@dcoutts 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
Copy link
Contributor Author

@ezyang 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 mentioned this issue Aug 24, 2016
1 of 8 tasks complete
@ezyang
Copy link
Contributor Author

@ezyang 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
Copy link
Contributor

@dcoutts 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
Copy link
Contributor Author

@ezyang 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?

@phadej
Copy link
Collaborator

@phadej phadej commented Feb 19, 2019

Bump. Should this be given higher prioritity? Writing

package local-foo
  ghc-options: -Werror

package local-bar
  ghc-options: -Werror

is tiresome.

@coot
Copy link

@coot coot commented Mar 15, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants