On Tue, Sep 13, 2016, at 16:24, Sven Panne wrote:
>
>* On Windows under a MinGW bash you get a a warning for ghci:
>
> $ stack --resolver=nightly-2016-07-01 exec ghci -- --version
> Run from outside a project, using implicit global project config
> WARNING: GHCi
Excerpts from Harendra Kumar's message of 2016-09-15 13:02:50 +0530:
> While I agree that stack.yaml is a frozen config, we do not necessarily
> need a separate config file or a separate format for that. My main point
> was a that a new user will have to understand two more languages
>
On 9/14/16 10:47 AM, David Feuer wrote:
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.
Also,
On 9/13/16 1:16 PM, Paolo Giarrusso wrote:
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
There are multiple ways to achieve this:
1) The env command being discussed is actually "stack exec env". Though it
includes the full environment rather than stack exclusive. You can use
"stack path" to print the stack exclusive environment. You can also use
"stack path --" to pick specific items
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
Stack *does* allow direct interaction with GHC:
stack exec -- ghc version
Granted this lacks a bit in brevity, but if you want to issue multiple
commands from "inside" stack's private environment, you can also just do
this:
stack exec sh
On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg
On Tue, Sep 13, 2016 at 3:14 PM, John Wiegley wrote:
> Some other tools provide an "env" sub-command, so that a person can run:
>
> eval $(stack env)
>
> And now ghc, ghci, etc., would be on the PATH, and the user doesn't really
> need to care about where it lives.
>
On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg
wrote:
> Other minor points:
> `stack env` does not work for me: my version of stack does not know how to
> `env`
>
I think they said that was an add-in. IIRC stack is extensible with
external commands, in roughly the same
On Tue, Sep 13, 2016 at 3:13 PM, Kyle Ondy wrote:
> On 16-09-13 12:07, Theodore Lief Gannon wrote:
> > Stack *does* allow direct interaction with GHC:
> >
> > stack exec -- ghc version
> >
> I find `stack ghc -- --version` to be a bit easier. Anything after the
> `--` is
> passed
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
11 matches
Mail list logo