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