Specifying flags for multiple packages

[lostman]

I have a collection of packages containing libraries/executables and I want to build them all. Each package contains a release flag which is used to tweak, among other things, ghc-options. For development I use -rtsopts -O1 to get speedier builds and tweak-ability; for release I use -O2 -Werror.

With cabal-install I can build the packages like this:

cabal install -frelease foo/ bar/ baz/ (1)

This doesn't seem possible with stack. It looks like I need to set the flags one by one:

flags:
  foo:
    release: true
  bar:
    release: true
  baz:
    release: true

And it is also hard to override the config from command line. Ideally I would like to set release: false in my stack.yaml and only make the release build when necessary.

Overriding the flags from command line is a little bit tedious:

stack build --flag foo:-release --flag bar:-release --flag baz:-release

Recovering the functionality of cabal-install example above (1) would be very useful. Perhaps:

stack build --flag \*:release

?

[chrisdone]

We did have global flags in the .yaml but they were removed, considered useless. I think adding them back shouldn't be problematic.

[lostman]

I think they're very useful! Or at least I haven't found alternative workflow to manage development/release for a single project that contains multiple packages.

[snoyberg]

I'm not opposed to adding this necessarily, but I do think that in general flags are misused in this way, leading to flags accidentally being turned on when they weren't intended. For the use case you describe, I typically achieve it just by passing in --ghc-options="..." on the command line. Is there a reason that doesn't work well in this case?

[chrisdone]

I imagine his use-case is like the development vs production flag typical of yesod projects?

[chrisdone]

(Although that's something that would be better passed as a command-line flag than put in a version controlled .yaml file.)

[snoyberg]

I think what I'm starting to get at is that maybe stack should have --devel and --release flags (or equivalent) which automatically pass in these kinds of GHC options, instead of having each .cabal file need to reimplement the same kind of logic.

[chrisdone]

What the cabal solution has is the ability to specify the -DDEVELOPMENT (or w/e) CPP flag, but also GHC options like -Wall -Werror or -O2, etc. So such a flag would be nice to be configurable in the .yaml.

[snoyberg]

Maybe we should just implement the simple thing now (support current workflows) and discuss adding a --devel flag separately.

[lostman]

@snoyberg fair point about turning flags on accidentally. Who knows what other flags are defined in the dependencies. I was mostly thinking about a single-project/multiple-packages case where I only want to pass the flags to my own projects all of which are in my local directory.

Normally I'd do something like this:

cabal install --only-dependencies --enable-tests foo bar baz
cabal install -frelease foo bar baz

[snoyberg]

@lostman I've added this on master with the syntax you mentioned. Can you test it out?

It would be trivial in the future to allow the cabal-install behavior of just --flag foo instead, if we think it's a good idea.