Add configure-options option

[borsboom]

I'm opening this issue discuss the possibility of adding a configure-options option, to add arguments passed to Setup.hs configure, as mentioned in #846 (among others).

I'm broadly in favour of the idea, with the following misgivings and design considerations.

Stack may not be using the Cabal library forever, in which case these options would no longer work. But moving away from Cabal is a ways off (if ever), and I think in that case we'd just bite the bullet and remove this option.

Some configure options must apply to all packages in a snapshot (e.g. --enable-library-profiling needs all packages to be built with that flag, and likely similar for --enable-split-objs), while others will work when only only to local packages or to targets. ghc-options can already suffer from similar problems and they're not handled very well right now, but it's more acute with configure-options. We'd need to be able to indicate which packages the configure-options apply to (e.g., all packages including snapshots, all local packages, or specific packages).

The alternative is that, when need for a new configure option is identified (e.g. in #1284 and #593), we add it to Stack explicitly. Since configure arguments will normally fall into two or three categories, it should be possible to modify the current design to make it quite easy to add these whenever the need comes up.

For either approach, Stack's current design doesn't handle the snapshots case very well, but extensible snapshots (#863, #1265) should fix that.

ping @mgsloan and @snoyberg

[fosskers]

I'm in favour of something akin to:

configure-options:
  "*": --enable-split-objs

as mentioned by @mgsloan in #1341 .

I found these threads after attempting to invoke -split-objs somehow with stack, and found it wasn't straightforward. I'm okay with having to wipe my package dbs and recompile my dependencies to account for new configuration options.

[fosskers]

Any thoughts on this @borsboom , @snoyberg , @mgsloan ?

[mgsloan]

@fosskers This'll be addressed along with the revamp of ghc-options, extra-deps, and implementation of custom snapshots. Other things have been taking priority over that, though, so it may be a while yet before that happens.

There's no strong reason to block implementation of this on those changes, though, so marking this "awaiting PR", feel free to implement.

[fosskers]

Thank you. In the interim, is there some other hacky way to use --enable-split-objs?

[mgsloan]

Hmm, does --ghc-options -split-objs work?

[fosskers]

If I already have an established ~/.stack with snapshots that weren't built with that option, then I'm seeing the same executable size before and after attemping that on a project of mine.

Testing

And the same after I completely wipe my ~/.stack and ./.stack_work. Binary size of final executable sitting at 8.2mb.

For reference, after wiping those directories and trying to build fresh, the command I use is: stack build --ghc-options="-split-objs"

So unless I'm doing something wrong, I have to say that this not working is probably a bug with stack.

[mgsloan]

The --ghc-options flag only affects local packges - http://docs.haskellstack.org/en/stable/yaml_configuration.html#ghc-options . Set apply-ghc-options: everything for them to apply to snapshot packages as well. Here's why this came into existence. This'll likely get cleaned up in the future, still some rough corners here.

[fosskers]

After making a completely clean stack environment, and putting the following in my stack.yaml:

ghc-options:
  "*": -split-objs

apply-ghc-options: everything

...among the usual settings, then building my project with stack build (all deps are pulled and built fresh), I still see no reduction in executable size.

[mgsloan]

Hmm, I'm not sure then, sorry. Perhaps --enable-split-objs has more effects in cabal than passing that flag into GHC

[acfoltzer]

I'd just like to add here that this would go a long way toward filling the gap left by MinGHC's death. When configuring a Windows system via Cygwin SSH, I had to go through the steps in #1714 to get a working cabal-install in the Stack snapshot.

[YPares]

Is it possible right now to pass a --with-gcc option to the configure process?
I'm not sure where this was left at.

[mgsloan]

As far as I know, --with-gcc is not currently supported, but it could potentially be considered under the umbrella of #652 . If a flag can be passed to cabal's configure step to make this happen, then this would be supported by #1438

[mgsloan]

Bumping to P1 due to popularity of this issue.

[sjakobi]

Is it possible right now to pass a --with-gcc option to the configure process?

This is now possible with #2264.

[mgsloan]

Marking this as blocked on the unification of flags and ghc-options - #849