I was investigating how to build for production (I'm on a Mac, I want to build for Linux), and noticed that there's a flag:
stack - The Haskell Tool Stack
Available options:
--os OS Operating system, e.g. linux, windows
I cannot find any documentation on this. If it's available I'd appreciate a nudge in the right direction, but otherwise, some documentation for the flag would be appreciated.
I understood the flag as being the target OS for builds, but when passing "--os linux" in a build on a Mac, I get a Mach-O binary, not a linux compatible binary.
Stack doesn't currently support cross-compilation, so I'm not sure what the point is of --os is. Looks like it was added in https://github.com/commercialhaskell/stack/commit/81a5f45b34c1b1e74a3570a71621244f2adcf450 for https://github.com/commercialhaskell/stack/issues/261, but I've only ever used --arch for that use case. @snoyberg, do you remember why you added --os at that time? Was it in anticipation of support doe cross-compilation in the future? I'm thinking it might be better to remove it for now unless we can document a use case for it.
@danpalmer: In terms of what you want to do, there's currently no officially supported method. However, it _is_ possible (though not officially supported) to use Stack's Docker integration on OS X, in which case it will build a Linux binary since the Docker container is running Linux. See https://github.com/commercialhaskell/stack/issues/194#issuecomment-146711019.
@borsboom Thanks for the clarification, using Docker was my first thought, but I'm encountering #2157 so it's not currently an option. I'll figure out a way to hack around this and build in docker myself.
(Of course documentation or removal of the flag would be greatly appreciated, I did spend quite a while looking into why it wasn't working and don't want others to have the same confusion)
I don't remember exactly why I added --os, but consistency seems like a good guess. I don't have any objection to either disabling the feature or marking it as "basically useless."
I'm in favor of removing the flag.
I think I have a use for the --os flag, but it's pretty obscure and probably not worth bringing the --os flag back for it: I'm investigating the dependencies of an internal package in hopes of getting it to build on HaLVM. For this use case, Stack's dependency graphing with stack dot seems to be the only usable version I can find [1]. What I would like to do is simply run stack dot --os halvm <package> to get the deps for the package for HaLVM; without setting the OS, I get spurious deps, e.g. base-compat depending on unix: https://github.com/haskell-compat/base-compat/blob/3007f1e583b1d037a9b24c473a85f7d531368d29/base-compat.cabal#L53.
[1] The cabal-db only works with Hackage packages, but this is an internal package. The ghc-pkg only works with installed packages, but the whole point is that I can't install the package in question yet.
@ntc2 Hmm, could bring back the flag possibly.
Alternatively, if you just need it for a one-off thing, could modify stack right here https://github.com/commercialhaskell/stack/blob/0f90bf4f7a3554f459e14be6abd445b4e7bcf3c1/src/Stack/Package.hs#L798
Replace packageConfigPlatform packageConfig instead with something like D.Platform D.X86_64 D.HaLVM or something like that.
@mgsloan, that worked after adding import qualified Distribution.System as D, thanks! And it does make quite a difference in this case:
$ diff -U0 prattle-deps-halvm.dot prattle-deps-linux.dot
--- prattle-deps-halvm.dot 2017-03-24 17:12:56.032676832 -0700
+++ prattle-deps-linux.dot 2017-03-24 16:35:45.314932660 -0700
@@ -6,3 +6 @@
-{rank=max; "HALVMCore"; };
-{rank=max; "XenDevice"; };
-{rank=max; "fail"; };
+{rank=max; "invalid-cabal-flag-settings"; };
@@ -12,12 +9,0 @@
-"Cabal" -> "array";
-"Cabal" -> "base";
-"Cabal" -> "binary";
-"Cabal" -> "bytestring";
-"Cabal" -> "containers";
-"Cabal" -> "deepseq";
-"Cabal" -> "directory";
-"Cabal" -> "filepath";
-"Cabal" -> "pretty";
-"Cabal" -> "process";
-"Cabal" -> "time";
-"Cabal" -> "unix";
@@ -25 +10,0 @@
-"MonadRandom" -> "fail";
@@ -27 +11,0 @@
-"MonadRandom" -> "primitive";
@@ -83,0 +68 @@
+"aeson" -> "uuid-types";
@@ -122 +107 @@
-"base" -> "integer-gmp";
+"base" -> "invalid-cabal-flag-settings";
@@ -156,4 +140,0 @@
-"cabal-doctest" -> "Cabal";
-"cabal-doctest" -> "base";
-"cabal-doctest" -> "directory";
-"cabal-doctest" -> "filepath";
@@ -250 +230,0 @@
-"distributive" -> "Cabal";
@@ -253 +232,0 @@
-"distributive" -> "cabal-doctest";
@@ -260,0 +240 @@
+"entropy" -> "unix";
@@ -286,2 +265,0 @@
-"hans" -> "HALVMCore";
-"hans" -> "XenDevice";
@@ -300,0 +279 @@
+"hans" -> "unix";
@@ -352,4 +330,0 @@
-"integer-logarithms" -> "array";
-"integer-logarithms" -> "base";
-"integer-logarithms" -> "ghc-prim";
-"integer-logarithms" -> "integer-gmp";
@@ -543 +517,0 @@
-"scientific" -> "integer-logarithms";
@@ -650,0 +625,7 @@
+"uuid-types" -> "base";
+"uuid-types" -> "binary";
+"uuid-types" -> "bytestring";
+"uuid-types" -> "deepseq";
+"uuid-types" -> "hashable";
+"uuid-types" -> "random";
+"uuid-types" -> "text";
Most helpful comment
I'm in favor of removing the flag.