search

haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.63k stars 695 forks source link

Flag field in cabal.project package stanza does not apply to build tools #7787

Open pranaysashank opened 3 years ago

pranaysashank commented 3 years ago

Describe the bug The solver doesn't seem to take into account constraints placed on packages in build-tool-depends.

To Reproduce With the following cabal file & the cabal.project file: --- chc.cabal

cabal-version:      3.6
name:               chc
version:            0.1.0.0
author:             pranaysashank
maintainer:         pranaysashank@gmail.com

executable chc
    main-is:          Main.hs
    build-depends:    base ^>=4.16.0.0
    build-tool-depends: happy:happy ^>=1.21.0
    hs-source-dirs:   app
    default-language: Haskell2010
-- cabal.project
packages:  ./

package happy
  flags: -bootstrap
$ cabal v2-build
Resolving dependencies...
Build profile: -w ghc-9.2.1 -O1
In order, the following will be built (use -v for more details):
 - happy-1.21.0 (exe:happy) (requires build)
 - chc-0.1.0.0 (exe:chc) (first run)
Starting     happy-1.21.0 (exe:happy)
Building     happy-1.21.0 (exe:happy)

Failed to build exe:happy from happy-1.21.0.
Build log (
/home/pranaysashank/.cabal/logs/ghc-9.2.1/happy-1.21.0-e-happy-60bda9d03a0488981bf080d8b712a1922aef99a5d52432048bbaabc1659bece1.log
):
Configuring executable 'happy' for happy-1.21.0..
Preprocessing executable 'happy' for happy-1.21.0..
cabal: The program 'happy' is required but it could not be found

cabal: Failed to build exe:happy from happy-1.21.0 (which is required by
exe:chc from chc-0.1.0.0). See the build log above for details.

Expected behavior Expect the build to succeed with happy package built with -bootstrap flag.

System information

fgaz commented 3 years ago

Looks related to #7189

pranaysashank commented 3 years ago

I saw that issue but don't think it's related.

I did some digging around in the code base and it looks like the issue is in constraintScopeMatches function, it gets a top level scope which is set in resolverParams function. Because of this constraintScopeMatches function returns False and the solver doesn't fail here in processPackageConstraintF and it doesn't reject the constraint with default flag +bootstrap.

I haven't seen the solver code before, so I could be wrong. But with that fixed I could get the package to build.

pranaysashank commented 3 years ago

Another reason I don't think it's related is because I can get it to build if I download it and add it to the packages list in cabal.project.

pranaysashank commented 3 years ago

See https://github.com/pranaysashank/cabal/commit/73669e41c79f693d15bb744a49f1f04c87a60642 which works for me.

pranaysashank commented 3 years ago

@grayjay looks like you have last touched this part of the code. Perhaps you can help?

grayjay commented 3 years ago

I think that the problem is that there currently isn't a way to specify whether a package section in cabal.project applies to all uses of the package (including use as a build tool) or only the top-level use. I think there is an issue for this, but I wasn't able to find it just now.

I was able to make the reproduction progress by using the more expressive constraint field to specify that all uses of happy should be built with -bootstrap, by adding "constraints: any.happy -bootstrap" to the top of cabal.project.

Another related issue is #3502, which would add constraint syntax for more of the constraint scope functionality that is already implemented in the solver. For example, it would allow constraining the bootstrap flag of happy only when it is used as a build tool for chc.

pranaysashank commented 3 years ago

@grayjay Thanks for the breakdown. The package also builds successfully with the flag if I unpack the happy package and add it to the packages section of the project file. Is this difference from when you're downloading from Hackage part of the same issue? I am assuming it works because the flag is applied to the package because its a target.

phadej commented 3 years ago

The package also builds successfully with the flag if I unpack the happy package and add it to the packages section of the project file.

Then it is also a local i.e. "top-level" package. i.e. package ... flags applies to it.

mpickering commented 1 year ago

You could also write.. which I imagine will satisfy this use case.

constraints:
    any.happy -bootstrap