Add experimental stack-based build system

[ianbollinger]

This adds support for building elm-platform version 0.15.1 from source using stack. All that's needed is the latest stack (via stack upgrade --git) and the 0.15.1 stack.yaml file. Then the user simply needs to run stack install and everything should just work. Then the user needs to either run stack install --jobs=1 or

stack install elm-compiler elm-package elm-make elm-repl && stack install elm-reactor

If they don't have the requisite GHC installed (in this case, 7.10), then stack will install the binary for them automatically after they run stack setup.

[jvoigtlaender]

I have no experience with the stack tool (so far have used Stackage only through cabal). It would of course be good to have this install path tested by a few people. Meanwhile, a few questions about what I see in the .yaml file:

• Why is it "#0.5" for elm-package? Shouldn't it be "#0.5.1" (and then maybe also a different commit)?
• Will the extra-deps setting fsnotify-0.1.0.3 work even though it contradicts what the resolver setting lts-3.2 implicitly declares for fsnotify?

[ianbollinger]

The 0.5 was a bad typo, now fixed. I double checked the SHA1 hash and it's correct.

As for fsnotify, stack appears to honor the versions in extra-deps over what's in the resolver's setting.

[ianbollinger]

Actually, it appears stack does support tags (instead of SHA1 hashes) even though the docs explicitly states it does not.

[jvoigtlaender]

Okay. Another question: How does this ensure that elm-reactor is built only after elm-make has been built and installed in a place where the build of elm-reactor can already call it? Is the order in which the packages are listed in the .yaml file relevant for this? (And a contraposited question: Does stack use parallel building, i.e., like cabal install -j does?)

[ianbollinger]

Those are excellent points. Yes, stack builds things in parallel, so this won't work if elm-reactor is built first (which is unfortunately a very common occurrence on my machine). The following does work, however:

stack install elm-compiler elm-package elm-make elm-repl
stack install elm-reactor

This is obviously a lot less convenient than just invoking stack install. 😦

[evancz]

I believe elm-make is listed as a dependency of elm-reactor so shouldn't that ensure that the order is correct?

[jvoigtlaender]

@evancz, no, there is no such dependency listed for elm-reactor (in the .cabal file). That's also why special care was needed in BuildFromSource.hs to make sure "by hand" that elm-reactor is built last.

I now wonder though: Shouldn't we be able to actually say in elm-reactor.cabal that it needs elm-make to be previously installed? Then both in BuildFromSource.hs and in the stack approach here, things should be more straightforward.

The .cabal file format has a field build-tools. Have you ever tried to use that in some way? Also, for Build-type: Custom, which elm-reactor is, there is a new Cabal feature, mentioned in here that allows declarations like (from an example in that post):

build-type: Custom

custom-setup
  setup-depends: base >= 4.6,
                 directory >= 1.0,
                 Cabal >= 1.18 && < 1.22,
                 acme-setup-tools == 0.2.*

Maybe that could be used to good effect.

[ianbollinger]

Unfortunately, stack seems to not respect dependencies in build-tools that are built in tandem; at least it didn't work when I tried it.

Also, it appears you can force stack to build things sequentially using stack build --jobs=1.

[evancz]

I think it makes sense to have docs about stack if core development switches to using stack. Until then, I do not want to "support" two different build paths. One is hard enough!