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