os/platform-specific fields in stack.yaml

[dtaskoff]

I think it would be nice to have a way of specifying fields that are os-specific. Something like this:

os-specific:
  windows:
    ghc-variant: integersimple
    flags:
      hashable:
        integer-gmp: false
      sceintific:
        integer-simple: true
...

Thus, one can keep more build information within stack and write less additional scripts.

NOTE: This could be possible also by modifying the confHook in Setup.hs if stack didn't bypass the configure step.

[mgsloan]

Potentially related issue: #2048

Adding conditionals could be a bit complicated, might be worth it though. I don't have a strong feeling about it, but historically we've avoided making the configuration format very fancy.

[decentral1se]

I would mark this as a duplicate of #2048, no?

#2048 (comment) seems to be the best solution for this so far.

[dtaskoff]

It's not a duplicate of it, although the mentioned solution works in this case too. However, I'm not talking about packages, I'm talking about all building flags/options, which could be different depending on the OSes.

[saurabhnanda]

Is there a way to specify platform specific stack overrides in my home folder, i.e. outside of the project root?

I'm on mac osx and need different cabal flags for hlibsass, while everyone else on my team is on linux and needs different flags.

[dtaskoff]

@saurabhnanda, if you need different cabal flags only, you can pass them to stack like this:
stack build --flag hlibsass:externallibsass

[pwaller]

Lacking this is a significant pain. For example, we build llvm-hs with -f-shared-llvm, except on Darwin, where this is not currently supported. The effect is that you must remember to pass --flags or use our custom make targets which pass appropriate --flags out according to your current environment.

If you ever use a stack command instead of make and forget to pass appropriate flags, it results in rebuilding the LLVM bindings and GTK (which requires --flag gtk:have-quartz-gtk on Darwin), which both take significant time.

[dbaynard]

To be clear, this is flags for dependencies, correct?

For a package itself one can use the os conditional in the cabal/hpack file.

One can set flags in a machine's config.yaml, rather than the project's stack.yaml. Would this work for your use case?

[pwaller]

To be clear, this is flags for dependencies, correct?

Yes. The packages whose flags need to be influenced are not under my control.

One can set flags in a machine's config.yaml, rather than the project's stack.yaml. Would this work for your use case?

That's not great either, since it is an additional step that must be documented and remembered to be done during setup of the machine. It would be much better if it were simply a property of the stack.

[dbaynard]

I can see good reasons to have such tooling. In one sense it is similar to haddock — often there are haddock build failures with dependencies, but stack currently has no way to indicate that a build should ignore these (the stackage-curator tool does, however).

This broadens the proposal slightly — perhaps it would be better to invert the tree:

ghc-variant:
  windows: integersimple
flags:
  hashable:
    windows:
      integer-gmp: false
  scientific [sic]:
    windows:
      integer-simple: true

That way any key (within some subset of the top level keys, perhaps) can have such conditionality.

---

For the examples I've seen, however, it seems the best case is actually to fix these issues upstream. For example, while it would be very useful to have the haddock workaround, the real fix would be for upstream libraries to fix their docs.

Likewise,

…we build llvm-hs with -f-shared-llvm, except on Darwin, where this is not currently supported.

Surely this should be fixed by llvm-hs setting that flag to false? And if they can't do that, you could fork the package, change the cabal file, and use a custom snapshot which uses your fork?

[pwaller]

Surely this should be fixed by llvm-hs setting that flag to false? And if they can't do that, you could fork the package, change the cabal file, and use a custom snapshot which uses your fork?

Well, whether to use shared llvm or not is a choice, depending on whether you want to statically compile your executable or not. I can see strong arguments for using either, but in my particular case I require them to be statically linked. I can't enforce that decision on the upstream project, it might not be appropriate for other users.

Something like gtk:have-quartz-gtk might be a bug, I don't know. I don't really understand why the default would be something that doesn't build (in fact fails with some quite bad error messages) on Darwin. But again in this case, I assume that it must be this way for a reason, and perhaps there are reasons I'm unaware of...

[dbaynard]

Ah, yes, if its a choice then that's different — and should be fixable without forking.