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

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

...

...

...

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