enable-split-objs #1284

[tinkyholloway]

Issue #1284 enable-split-objs

This PR adds an enable-split-objs option to config which takes a boolean value (defaulting to false).

When set true, stack builds new libraries passing the --enable-split-objs option to cabal.

The result is that these libraries are built with multiple object files per module which results in unused functions not being linked into final executables. It's been reported that this can result in significantly reduced size binaries which can be advantageous in some deployments.

The correctness of the change can be confirmed by running ar -t on the resulting new library builds with the option set true, set false, or removed from config.yaml.

Use:

1. start from a clean ~/.stack/ (previously built libraries need to be removed and rebuilt)
2. add enable-split-objs: true to a newly created ~/.stack/config.yaml
3. in project directory: stack clean, stack build

[mgsloan]

Cool, thanks for working on this!

Maybe it would be good to handle flags like this similarly to ghc-options? See my last comment on #846

We should also consider whether this flag should be part of the config cache, and instead get added here, so that the packages get reconfigured properly when this flag changes. Since this adds the flag directly to the invocation of configure, using --enable-split-objs doesn't force a reconfigure for all the packages.

[tinkyholloway]

Thanks @mgsloan for reviewing my PR.

Maybe it would be good to handle flags like this similarly to ghc-options? See my last comment on
#846

I can do this. Are you saying that you see this as being a "per-package" flag? It seems to me that --enable-split-objs only makes sense if enabled globally.

We should also consider whether this flag should be part of the config cache, and instead get added
here

I'm not sure I understand this enough to comment. Does this mean that if the flag state changes in the project, then the project is rebuilt with the new flag state? Can it be forced to rebuild dependencies if the flag state changes?

[mgsloan]

Are you saying that you see this as being a "per-package" flag? It seems to me that --enable-split-objs only makes sense if enabled globally.

Right, I imagine that --enable-split-objs would usually be used like this:

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

I think adding something like this makes sense, otherwise, to cover everyone's usecases we'll need to re-wrap every flag `runhaskell Setup.hs configure" can take.

I'm not sure I understand this enough to comment. Does this mean that if the flag state changes in the project, then the project is rebuilt with the new flag state? Can it be forced to rebuild dependencies if the flag state changes?

Yes, that's what it means. However, it does not force a rebuild of snapshot dependencies. I'm not sure what we should do about that. The snapshot packages are shared among multiple projects, and some might want --enable-split-objs while others do not. I think this deserves some further consideration.

However, for now, it's fine to just go with the same semantics as ghc-options - see the caveat mentioned in the docs.

[borsboom]

@tinkyholloway Thanks for your work on this so far. It's clear from the discussion here that we need to make some deeper design decisions, so I'd like to move the discussion from here to #1438.

I'm going to close this PR for now, and we can revisit it once Stack's design can handle this case better.

[mgsloan]

Since we haven't yet done the revamp of ghc-options / cabal-options, I figured it'd be good to revisit this. Sorry for rejecting the PR, I've added the --split-objs, but marked with EXPERIMENTAL and a number of caveats.