Cabal: How to enable flag for single package only?

[phadej]

• http://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-build Doesn't mention almost any flags.
• http://cabal.readthedocs.io/en/latest/installing-packages.html#controlling-flag-assignments gives impression it's impossible

[23Skidoo]

So basically flag constraints should be better documented and referred to from more places?

[phadej]

I tried

cabal new-build -fservant-js:example servant-js:counter

and cabal silently succeed with

Resolving dependencies...
Up to date

so there's an UX and documentation problem. For now I'm ok with if someone tells how to do what I want

[23Skidoo]

Does new-build --constraint "servant-js +example" work for you?

[phadej]

Just "found" it myself. Yeah, it works. Thanks!

---

definitely an UX problem:

• universal flag: -fflag
• per-package flag: --constraint "pkg +flag"

[ezyang]

-fflag doesn't mean universal flag. It originates as a flag to ./Setup configure, where it sets the flag of the package being configured. This is related to #4272, since new-build shouldn't accept this flag, it only makes sense if there is a unique package you are configuring (or maybe it applies just to local packages? I don't recall the semantics here.)

UPDATE: Re documentation, at the end of http://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-build it says:

Beyond a list of targets, cabal new-build accepts all the flags that cabal new-configure takes. Most of these flags are only taken into consideration when building local packages; however, some flags may cause extra store packages to be built (for example, --enable-profiling will automatically make sure profiling libraries for all transitive dependencies are built and installed.)

When I look at cabal new-configure, I see:

cabal new-configure inherits options from Cabal. semantics:

Any flag accepted by ./Setup configure.
Any flag accepted by cabal configure beyond ./Setup configure, namely --cabal-lib-version, --constraint, --preference and --solver.
Any flag accepted by cabal install beyond ./Setup configure.
Any flag accepted by ./Setup haddock.

As an added bonus, when I look at the documentation of --flag http://cabal.readthedocs.io/en/latest/nix-local-build.html#cfg-field-flags I see:

A common mistake is to say cabal new-build -fhans, where hans is a flag for a transitive dependency that is not in the local package; in this case, the flag will be silently ignored. If haskell-tor is the package you want this flag to apply to, try --constraint="haskell-tor +hans" instead.

So, the problem is not that the docs don't exist. @phadej, how do you think we can make this more discoverable?

[ezyang]

Related to discovery on the command line: #937 on warning when -f doesn't exist. (It's not entirely trivial to say what the correct semantics are.)

[phadej]

I didn't look in "5.5. Configuring builds with cabal.project", as it doesn't mention flags in the title.

The documentation contradicts with your claim:

Flags are per-package, so it doesn’t make much sense to specify flags at the top-level, unless you happen to know that all of your local packages support the same named flags. If a flag is not supported by a package, it is ignored.

---

IMHO it's bad idea to inherit "Any flag accepted by ./Setup configure.". Examples:

--global
--package-db

or

--reinstall
--avoid-reinstalls
--force-reinstalls
--upgrade-dependencies

--root-cmd=COMMAND               (No longer supported, do not use.)

--enable-tests is crippled. What if I want everything and tests from few packages. Or, as I needed today, build everything except single test-suite in one package in multi-package project. IIRC Duncan is working ona new target specifying syntax, and when it's done, also --enable-benchmarks should be deprecated.

I'm not insist on removing, but specifying that flag should issue a warning, guiding what's the new preferred way.

---

as overall comment: there is so much different flags in --help output, that it would make sense to group them.

[phadej]

Solutions:

in cabal.project

package foo
  flags: your-flag

or

constraints: foo +your-flag

Latter works in cli as --constraint='foo +your-flag.

[phadej]

Reopened, this is a documentation issue. package flags doesn't have any hits in https://cabal.readthedocs.io/en/latest/nix-local-build.html

[hasufell]

@phadej I also dicsovered that

package foo
   flags: -bar

Doesn't do anything (silently) when there is a freeze file that forces constraint foo +bar. Only when adding constraints: foo -bar the invalid configuration becomes visible.