Open phadej opened 7 years ago
So basically flag constraints should be better documented and referred to from more places?
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
Does new-build --constraint "servant-js +example"
work for you?
Just "found" it myself. Yeah, it works. Thanks!
definitely an UX problem:
-fflag
--constraint "pkg +flag"
-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?
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.)
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:
--user
--global
--package-db
or
--shadow-installed-packages
--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.
Solutions:
in cabal.project
package foo
flags: your-flag
or
constraints: foo +your-flag
Latter works in cli as --constraint='foo +your-flag
.
Reopened, this is a documentation issue. package flags
doesn't have any hits in https://cabal.readthedocs.io/en/latest/nix-local-build.html
@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.
per package flags still needs at least an usage example (in cabal.project
reference I guess)
BTW, is the syntax for many flags per package just many lines as above, repeating the common part, or can this be collated?