Given how nice stack makes installing GHC and switching between different versions, it would be great if it could do the same for the LLVM backend. Maybe by default, maybe only after a stack setup on a project with -fllvm.
I recently tried to install LLVM with brew for GHC + stack and was unsuccessful. Using different GHC versions with their different LLVM version requirements would probably be rather annoying and make builds no longer fully reproducible in case the installed LLVM changes.
I don't know if you consider this to be in the scope of the stack tool, but since stack already installs other various pieces of build infrastructure like MSYS on Windows platforms, I thought I would at least suggest it.
@blitzcode Can you try with Stack Nix support?
I tried it on Ubuntu and it is easy to do: if you have Nix installed and a recent stack you can build your project with:
stack --nix-packages llvm_35 build --ghc-options=-fllvm
(of course, all these options can also be put in config files. Along with a fixed resolver (like lts-4.1) this means the build is fully reproducible, LLVM and GHC versions being fixed)
and run it with:
stack --nix exec your-exe
@blitzcode I just tried it on OSX (El Capitan), with stack 1.0.2 (installed with brew), and this works too.
Nix-installed LLVM doesn't seem to cause the issues you have with brew-installed LLVM. (GHC 7.X requires LLVM 3.5)
@YPares Thanks for the suggestion. I' not familiar with nix beyond the elevator pitch for it, but I gave it a try. I couldn't really get anything build this way. Most of my projects use the OpenGL packages, and it seems that library can't find the OpenGL headers under the nix build environment. I tried a few others with similar results. Just trying a simple project doesn't seem to work either:
$ stack new llvmtest simple
$ stack --nix-packages llvm_35 build --ghc-options=-fllvm
error: attribute ‘lts-5_1’ missing, at (string):1:320
(use ‘--show-trace’ to show detailed location information)
(a plain stack build works just fine, OS X 10.10)
That's all maybe worth a separate bug report, though. I used the LLVM backend with an LLVM build from source a couple of times with 7.6/7.8, had various compiler crashes and runtime issues back then. I never got it to work with 7.10. It seems like it's all still very much work-in-progress. Anything that makes using the LLVM backend more reliable / simpler would be much appreciated!
@blitzcode can't comment on the OpenGL headers thing (I'm not on Darwin), and not sure whether using --nix really is your best option here. But just to say that I tried your sequence of commands and it works fine here. You should make sure that you're tracking the nix-unstable channel and do a nix-channel --update, otherwise Nix won't know about very recent snapshots such as LTS-5.1. This is explained in the guide: http://docs.haskellstack.org/en/stable/nix_integration.html#additions-to-your-stack-yaml.
@mboes Thanks, that seems to be the issue! I didn't know that error message was actually from Nix. I also didn't think that stack would use Nix to resolve the actual Haskell dependencies.
I'm interested in LLVM for Windows automatically installed with stack setup. Will that be added to stack planning?
@varosi Not on the immediate agenda, but if someone were to implement it, it's likely it would be merged.
The easiest option may be to simply include the correct version of LLVM in the GHC bindists. This would also prevent using the wrong version of LLVM.
Most helpful comment
The easiest option may be to simply include the correct version of LLVM in the GHC bindists. This would also prevent using the wrong version of LLVM.