Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

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 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.

...

How would I use stack with a GHC 8.0.2 release candidate?

On 13 September 2016 at 21:27, Christopher Allen 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

...

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

...

...

...

...

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

...

...

...

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

On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow wrote: libraries 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