I don't think anyone thinks it's bad to have a --with-ghc option, AFAIK the only reason it hasn't been done is lack of desire/time, since it's an uncommon workflow. Unlike with cabal, the normal way to specify a different GHC is with the `--resolver` setting. AFAIK, this flag could be added.
On Wed, Sep 14, 2016 at 6:54 PM, Simon Marlow <marlo...@gmail.com> wrote: > But what if I don't want to fiddle with my PATH? Why is it so bad for > stack to have a --with-ghc option to tell it what GHC to use? > > On 14 September 2016 at 16:23, Christopher Allen <c...@bitemyapp.com> > wrote: > >> Probably pretty similarly to how we use patched GHCJS at work with Stack. >> >> -- from the stack.yaml >> system-ghc: true >> compiler: ghcjs-0.2.0_ghc-7.10.2 >> resolver: ghcjs-0.2.0_ghc-7.10.2 >> >> -- in the Makefile >> ghcjs: >> git clone https://github.com/myorg/ghcjs >> cd ghcjs && stack setup && stack install >> cd ghcjs && stack install cabal-install alex happy >> cd ghcjs && stack exec -- ghcjs-boot --dev --no-haddock >> >> It's just picking GHCJS up from the path, with system-ghc: true, we're >> telling it that is kosher. >> >> We disable system-ghc usage for regular GHC projects, it makes >> profiling less convenient than if you use a Stack managed GHC but if >> you're doing GHC dev the difference means nothing. >> >> On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow <marlo...@gmail.com> wrote: >> > How would I use stack with a GHC 8.0.2 release candidate? >> > >> > On 13 September 2016 at 21:27, Christopher Allen <c...@bitemyapp.com> >> wrote: >> >> >> >> Stack is not your shell, a build script, or a Makefile. It already has >> >> path management for the GHC installations it provisions and supports. >> >> It is not Stack's job to mutilate your path to support external GHC >> >> installations. >> >> >> >> Make a Makefile or add shortcuts to your bashrc to switch compilers. >> >> >> >> On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso < >> p.giarru...@gmail.com> >> >> wrote: >> >> > On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher >> Allen >> >> > wrote: >> >> >> >> >> >> Stack users are moving away from enabling system installed GHCs by >> >> >> default because it breaks the ease of enabling profiling for >> libraries >> >> >> when you're using a Stack-installed GHC. >> >> > >> >> > >> >> >> >> >> >> I'm not sure why multiple system-installed GHCs needs to be >> supported >> >> >> in addition to the GHC support Stack already provides. That's extra >> >> >> work for...what? Stack isn't trying to compete with Nix. It's more >> >> >> like a blend of rustup and cargo -- or Clojure's Leiningen. >> >> > >> >> > >> >> > To clarify: I'm not proposing stack to install those GHCs, just to >> use >> >> > them. >> >> > >> >> > I think the extra work would be limited (calling GHC-X.Y.Z instead of >> >> > GHC) >> >> > and has other technical advantages >> >> > (https://github.com/commercialhaskell/stack/issues/2433). Mind you, >> I'm >> >> > willing to contribute the work and not asking anybody—I've just been >> >> > busy. >> >> > >> >> > Right now I have to modify the PATH every time I use GHC 7.8.4 >> because I >> >> > needed to customize the build (I'm on OS X 10.11), but I still want >> GHC >> >> > 8 by >> >> > default. >> >> > >> >> >> >> >> >> On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso < >> p.gia...@gmail.com> >> >> >> wrote: >> >> >> > >> >> >> > >> >> >> > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard >> Eisenberg >> >> >> > wrote: >> >> >> >> >> >> >> >> Thanks, many, for explaining better ways to interact directly >> with >> >> >> >> GHC >> >> >> >> after using a `stack setup`. Perhaps, then, all that’s stopping >> >> >> >> someone >> >> >> >> like >> >> >> >> me from liking the ease of `stack setup` is a little missing PR >> (as >> >> >> >> in, >> >> >> >> public relations). I understand that many people want to keep GHC >> >> >> >> cloistered >> >> >> >> away to ease version swapping, but others (like me) want GHC >> >> >> >> available >> >> >> >> front >> >> >> >> and center. >> >> >> >> >> >> >> >> Other minor points: >> >> >> >> `stack env` does not work for me: my version of stack does not >> know >> >> >> >> how >> >> >> >> to >> >> >> >> `env`. >> >> >> > >> >> >> > >> >> >> > That's correct—stack env was a feature request. >> >> >> > >> >> >> > The warning on `stack ghci` doesn't happen usually, but I'd say >> >> >> > that's a >> >> >> > bug >> >> >> > (probably because it's a new install)? >> >> >> > >> >> >> > I use stack (and have contributed a bit recently), but I agree >> >> >> > there's a >> >> >> > few >> >> >> > things stack could do better for this workflow. >> >> >> > >> >> >> > And the transition has a rather annoying learning curve—stack ghci >> >> >> > and >> >> >> > stack >> >> >> > ghc are not the same as ghci/ghc. I think that's on purpose to >> >> >> > support a >> >> >> > project-based workflow, and it has upsides, but it's a transition >> >> >> > pitfall. >> >> >> > Lots of things *are* explained in >> >> >> > https://docs.haskellstack.org/en/latest/faq/, but you do need >> learn a >> >> >> > few >> >> >> > things from scratch. >> >> >> > >> >> >> > You want stack exec ghc and stack exec ghci, and arbitrary options >> >> >> > require a >> >> >> > double dash `--` — use `stack ghc -- --version` or `stack exec -- >> ghc >> >> >> > --version`. And I'm afraid the command syntax is mostly frozen by >> >> >> > now. >> >> >> > >> >> >> > To support a compiler-based workflow, there are a few things >> >> >> > planned—I >> >> >> > opened an issue to collect them, starting from Simon Marlow's >> recent >> >> >> > email: >> >> >> > https://github.com/commercialhaskell/stack/issues/2546 >> >> >> > >> >> >> > BTW, a system-installed GHC already works if you stick to one (and >> >> >> > only >> >> >> > build projects that need that). But I'd love to support multiple >> >> >> > system-installed GHCs and being able to pick the one you need. >> >> >> > >> >> >> > As others already explained, giving access to stack-installed GHCs >> >> >> > can >> >> >> > be >> >> >> > problematic—they're going to work, in part, exactly because you >> can't >> >> >> > install in their package database. >> >> >> > >> >> >> > Having stack install system-wide GHCs would IMHO risk opening a >> can >> >> >> > of >> >> >> > worms—having working binaries for all Linux distros requires some >> >> >> > work, >> >> >> > system installers would be harder and most users would dislike >> them. >> >> >> > >> >> >> > _______________________________________________ >> >> >> > Haskell-Cafe mailing list >> >> >> > To (un)subscribe, modify options or view archives go to: >> >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> > Only members subscribed via the mailman list are allowed to post. >> >> >> >> >> >> -- >> >> >> Chris Allen >> >> >> Currently working on http://haskellbook.com >> >> >> _______________________________________________ >> >> >> Haskell-Cafe mailing list >> >> >> To (un)subscribe, modify options or view archives go to: >> >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> Only members subscribed via the mailman list are allowed to post. >> >> >> >> >> >> >> >> -- >> >> Chris Allen >> >> Currently working on http://haskellbook.com >> >> _______________________________________________ >> >> Haskell-community mailing list >> >> Haskell-community@haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> > >> > >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. >
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community