New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specifying flags for multiple packages #335

Closed
lostman opened this Issue Jun 17, 2015 · 12 comments

Comments

Projects
None yet
3 participants
@lostman

lostman commented Jun 17, 2015

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

This comment has been minimized.

Member

chrisdone commented Jun 17, 2015

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

@lostman

This comment has been minimized.

lostman commented Jun 17, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 17, 2015

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?

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jun 17, 2015

@chrisdone

This comment has been minimized.

Member

chrisdone commented Jun 17, 2015

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

@chrisdone

This comment has been minimized.

Member

chrisdone commented Jun 17, 2015

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 17, 2015

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

This comment has been minimized.

Member

chrisdone commented Jun 17, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jun 17, 2015

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

@lostman

This comment has been minimized.

lostman commented Jun 18, 2015

@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 snoyberg self-assigned this Jun 23, 2015

snoyberg added a commit that referenced this issue Jun 23, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 23, 2015

@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.

@snoyberg snoyberg modified the milestone: 0.2.0.0 Jun 23, 2015

@snoyberg snoyberg removed their assignment Jun 23, 2015

@lostman

This comment has been minimized.

lostman commented Jun 24, 2015

👍

Works great.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 24, 2015

Cool

@snoyberg snoyberg closed this Jun 24, 2015

@snoyberg snoyberg removed the in progress label Jun 24, 2015

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