let "cabal configure -fSomeFlag" produce error for undeclared flags #937

Open
bos opened this Issue May 24, 2012 · 8 comments

Comments

Projects
None yet
4 participants
Contributor

bos commented May 24, 2012

(Imported from Trac #947, reported by Oblosys on 2012-04-27)

Typos in flags can lead to confusing problems, especially with large projects that take a long time to build. A simple check could be quite useful:

~> hconfigure -fNonExistentFlag -fSomeFlag
cabal: undeclared flag 'NonExistentFlag'. Declared flags are:
  ExistentFlag, SomeFlag
Contributor

bos commented May 24, 2012

(Imported comment by @kosmikus on 2012-04-27)

There are a few things to keep in mind:

  • Flag constraints can be given for arbitrary packages, not just for targets.
  • It multiple targets are specified, -f flags apply to all targets.
  • Not every version of a package declares the same flags.
So whatever we end up doing: a warning might be ok, an error almost certainly isn't. Even a warning has to be designed carefully so that it isn't just perceived as noise.

It seems that warnings for 'cabal install -fsomeFlag' are difficult to get right.
However, I think for 'cabal configure -fsomeFlag' its considerably simpler, right?

Oblosys commented Jul 17, 2012

You're right, it's actually cabal configure I was thinking of (hconfigure above is an alias for cabal configure).

@kosmikus, what are the arbitrary packages you mention? As far as I can see, cabal flags do not apply to dependencies (which seems correct behavior to me.) Therefore, if you do a cabal configure (or a cabal install) on a local package, an error message might be viable, since the flags will apply only to a single version of a single package.

When using cabal install for a package on hackage, the situation is different indeed. In case of multiple targets, an error would be wrong and even a warning will be a bit strange. On the other hand, in case of a single target, a warning may be desirable if the version chosen by cabal does not support all of the flags provided.

On Tue, 17 Jul 2012, Martijn Schrage wrote:

When using cabal install for a package on hackage, the situation is
different indeed. In case of multiple targets, an error would be wrong
and even a warning will be a bit strange. On the other hand, in case of
a single target, a warning may be desirable if the version chosen by
cabal does not support all of the flags provided.

Also if you have a single target, the target may depend on multiple
packages and the cabal flag applies to all packages that are freshly
installed. (As far as I know, packages will not be reinstalled when they
are affected by a flag change. But since the API of a package must not
depend on cabal flags, this is certainly ok.)

Oblosys commented Jul 17, 2012

That's what I thought, but when I actually tried this, I found that the flags only apply to the target itself. I tested it by installing aeson-4.0.1 with -f-native. This will install the dependent package blaze-textual, which contains a module Blaze.Text.Double.Native based on the flag 'native', which defaults to true. (the module is not exposed, but you can check its existence with ghci)

To me this seems the right behavior, because otherwise whether or not your flags apply will depend on whether or not some package was already installed. This holds for the target as well of course, but for one package it's less confusing.

ezyang changed the title from let "cabal -fSomeFlag" produce error for undeclared flags to let "cabal configure -fSomeFlag" produce error for undeclared flags Dec 24, 2015

Contributor

ezyang commented Dec 24, 2015

To summarize, I think the following behavior is requested:

  1. If "cabal configure" is called with an -f argument for a non existent flag, we should error.
  2. If "cabal install foo-0.1" is called with an -f argument for a non existent flag, we should error.
  3. If "cabal install foo" is called with an -f argument for a non existent flag, we should warn. Something like, "Attempted to set flag -ffoo, but the selected foo-0.1 does not have any such flag"
  4. If "./Setup configure" is called with an -f argument for a non existent flag, we should error. (This implies that cabal install MUST NOT pass bogus flags to the setup script; if it decides that the flag does not exist, it must warn and then not pass it on.)

On Wed, 23 Dec 2015, Edward Z. Yang wrote:

To summarize, I think the following behavior is requested:

  1. If "cabal configure" is called with an -f argument for a non existent flag, we should error.
  2. If "cabal install foo-0.1" is called with an -f argument for a non existent flag, we should error.
  3. If "cabal install foo" is called with an -f argument for a non existent flag, we should warn. Something like,
    "Attempted to set flag -ffoo, but the selected foo-0.1 does not have any such flag"
  4. If "./Setup configure" is called with an -f argument for a non existent flag, we should error. (This implies that
    cabal install MUST NOT pass bogus flags to the setup script; if it decides that the flag does not exist, it must warn
    and then not pass it on.)

How to cope with multiple packages, e.g. "cabal install -fsomeFlag bar-0.1 foo" ?

Contributor

ezyang commented Dec 24, 2015

Good question. I think there are two possibilities.

POSSIBILITY ONE: Flag assignments apply to all explicitly specified packages (but not recursively depended upon ones. If "cabal install foo bar" is called with an -f argument for a non existent flag for both selected versions of foo and bar, we error "Attempted to set flag -ffoo, but none of the selected packages have this flag." Maybe we can even give a nice hint when a transitively depended upon package has the flag (suggesting the user explicitly specify it.) Thus, there is no way using -f to say "enable -fdebug on foo, but not bar". We would have to add a separate, per package flag assignment flag. (The semantics of that reflect the single package install case.)

POSSIBILITY TWO: -f arguments when there are multiple packages are illegal. Ask users to use the per-package flag assignment interface.

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