While we're griping about stack: it seems to place compiler output from -ddump-... in mysterious places that are hard to find without Google, and (worse) it seems to do something with stack test output that even Google can't discover.
On Sep 14, 2016 11:59 AM, "Michael Snoyman" <mich...@snoyman.com> wrote: > 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-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
