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

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 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 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: p.giarrusso@gmail.com> libraries p.gia...@gmail.com> 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.