{"action":"created","issue":{"url":"https://api.github.com/repos/commercialhaskell/stack/issues/1190","labels_url":"https://api.github.com/repos/commercialhaskell/stack/issues/1190/labels{/name}","comments_url":"https://api.github.com/repos/commercialhaskell/stack/issues/1190/comments","events_url":"https://api.github.com/repos/commercialhaskell/stack/issues/1190/events","html_url":"https://github.com/commercialhaskell/stack/issues/1190","id":112004864,"number":1190,"title":"Support using stackage snapshots with GHCJS","user":{"login":"mgsloan","id":22570,"avatar_url":"https://avatars.githubusercontent.com/u/22570?v=3","gravatar_id":"","url":"https://api.github.com/users/mgsloan","html_url":"https://github.com/mgsloan","followers_url":"https://api.github.com/users/mgsloan/followers","following_url":"https://api.github.com/users/mgsloan/following{/other_user}","gists_url":"https://api.github.com/users/mgsloan/gists{/gist_id}","starred_url":"https://api.github.com/users/mgsloan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mgsloan/subscriptions","organizations_url":"https://api.github.com/users/mgsloan/orgs","repos_url":"https://api.github.com/users/mgsloan/repos","events_url":"https://api.github.com/users/mgsloan/events{/privacy}","received_events_url":"https://api.github.com/users/mgsloan/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-10-18T07:02:53Z","updated_at":"2015-10-19T03:45:28Z","closed_at":null,"body":"Currently, stack only supports GHCJS via a compiler resolver that looks like `ghcjs-0.1.0.20150924_ghc-7.10.2`.\r\n\r\nI can think of a couple ways to add support:\r\n\r\n1) Add a `--ghcjs` flag and `ghcjs: True` config field, for use with snapshot resolvers.  This is consistent with needing to pass in `--ghcjs` to cabal.\r\n\r\n2) Have some sort of snapshot resolver modifier which specifies to use GHCJS.  For example `ghcjs-lts-3.9`.  Note that there wouldn't be an actual snapshot, though.  This would preserve the property that the resolver specifies which compiler is being used.  Not sure if this is a big deal or not, but having compiler revolvers suggests that the resolver specifies a particular compiler.\r\n\r\n3) Add a `ghcjs-packages` field which lists the packages to build with GHCJS.  This would be a more involved change.  This would simplify building client and server in one go and ensure that your serverside code and clientside code are using the same dependencies - no need to make sure your resolvers match.  Some notes on this:\r\n\r\n  - The change would be pretty substantial.  Currently, we know what compiler we're using when executing a stack command in the presence of a build config.  This would make it more of a thing that's part of planning / executing the build.\r\n\r\n  - It would need to be decided whether packages compiled by both GHC and GHCJS should need to be listed in `ghcjs-packages`.  We could figure out all the local packages depended on by ghcjs packages, but I imagine some code would need to be written for that.\r\n\r\n  - `solver` would use `--ghcjs` with cabal whenever there's a ghcjs package.  This would mean that we'd be using GHCJS's global DB, which could potentially have different versions (but hopefully not)\r\n\r\n  - `ghci` would need to take a `--ghcjs` flag for cases where the targets can either be built with GHC or GHCJS.\r\n\r\nIt's also worthwhile to consider what to do in similar situations in the future, where we have ghc based compilers which should be used to build some of your local packages.  Perhaps if we put the effort into doing (3), it should be generalized?\r\n\r\nI'm leaning towards (1) for consistency with the existing GHCJS ecosystem / philosophy.  This way, if an application works with ghcjs as well as ghc, you can just do a `stack build --ghcjs`.  I don't think the effort and complexity of (3) is worth it.  It does mean that the compiler is no longer determined by the resolver.  But, in a sense, this was always the case since we don't demand a particular GHC version (unless `compiler-check: match-exact`)."},"comment":{"url":"https://api.github.com/repos/commercialhaskell/stack/issues/comments/149088996","html_url":"https://github.com/commercialhaskell/stack/issues/1190#issuecomment-149088996","issue_url":"https://api.github.com/repos/commercialhaskell/stack/issues/1190","id":149088996,"user":{"login":"3noch","id":882455,"avatar_url":"https://avatars.githubusercontent.com/u/882455?v=3","gravatar_id":"","url":"https://api.github.com/users/3noch","html_url":"https://github.com/3noch","followers_url":"https://api.github.com/users/3noch/followers","following_url":"https://api.github.com/users/3noch/following{/other_user}","gists_url":"https://api.github.com/users/3noch/gists{/gist_id}","starred_url":"https://api.github.com/users/3noch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/3noch/subscriptions","organizations_url":"https://api.github.com/users/3noch/orgs","repos_url":"https://api.github.com/users/3noch/repos","events_url":"https://api.github.com/users/3noch/events{/privacy}","received_events_url":"https://api.github.com/users/3noch/received_events","type":"User","site_admin":false},"created_at":"2015-10-19T03:45:28Z","updated_at":"2015-10-19T03:45:28Z","body":"I'm highly ignorant of the GHCJS ecosystem, so I might be way off base:  Wouldn't using the *exact* same snapshot (except for compiler) for both GHC and GHCJS projects be problematic? Many packages that target GHCJS will optionally depend on GTK+ when built with GHC. So your GHCJS snapshots would need to include GTK+ bindings, which won't build. Still, I can certainly see the value of having GHCJS snapshots mirror their GHC counterparts. I would be slightly concerned that tests that pass with one compiler might fail for another (especially considering the tests may differ between the two).\r\n\r\nIt seems to me that you would still be better off separating GHC and GHCJS snapshots from each other, but with the added caveat that they should mirror each other for the packages that they do have in common.\r\n\r\nAlso, considering that no GHCJS code and GHC code will ever need to \"link,\" there is really no reason to fear having two entirely different snapshot versions for each of them (e.g. a server package using LTS-3.9 and a front-end package using GHCJS-LTS-3.8). No doubt, this might not be ideal purely from \"consistency\" perspective, but I don't see any technical dangers arising from it.\r\n\r\nWith all this in mind, if you wanted stack to support having the *same* `stack.yaml` file define how to build an entire system (with some packages using GHC and others using GHCJS), it seems that the the `resolver` configuration then needs to live beneath another, even broader setting, like \"ecosystem\" or something. So a `stack.yaml` file might look like this:\r\n\r\n```yaml\r\necosystem: ghc\r\n  - resolver: LTS-3.9\r\necosystem: ghcjs\r\n  - resolver: GHCJS-LTS-3.8\r\n```\r\n\r\nThis is likely a terrible idea (because I'm way out of the loop on this stuff), but you get the idea.\r\n\r\nP.S. Great work. I'm so excited where all this is going. I recently compiled reflex-todomvc with stack. Amazing."}}