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-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community