On Wed, Jul 10, 2024 at 12:52:10PM +0200, Tom Smeding wrote:
> [...]
> Furthermore, as already noted indirectly by Oleg, GHC environment files are
> human-readable, if not very easily human-writable.
They're actually pretty human-writable too. The script I've written to regain
simple ghci workflo
Hi Simon,
The direct answer to your particular problem is that cabal-install-3.10.1
(which you're using) does not add `base` in the package environment created
by `install --lib` by default.
So, to fix the problem you'd need to say `cabal install --lib base
hashtables primitive` instead.
Better ye
So far, the discussion around environment files in this thread has
always been entangled with the idea of a "global state". GHC environment
files (as written by `cabal install --lib`) are only global if they are
placed in a directory where GHC will always look regardless of where GHC
is current
Reading this certainly motivates me to push for a better design of the
respective boundaries of GHC and cabal. Removing magic from GHC that it
uses to compensate for the absence of cabal or other build system would
certainly help using it for simpler use-cases.
Le 10/07/2024 à 11:53, Oleg Gren
On 10.7.2024 11.27, Simon Peyton Jones wrote:
I wonder if there is an articulate writeup of Cabal's mental model.
Sadly, i'm not aware of any. I'm also afraid, that Duncan's (who made
initial v2-setup), Herbert's (who pushed v2 over the line) and mine
models differ at least slightly.
The
Oleg (a cabal hero, btw, thank you Oleg) writes
`cabal-install` (and `stack` FWIW) don't want you to have any (implicit)
state. That's not great for "real world projects".
But you necessarily have global state anyway! When I say `ghc -c Foo.hs` I
get a particular Prelude, which in turn depends
On Tue, Jul 09, 2024 at 08:50:18PM +0300, Oleg Grenrus wrote:
> cabal-install has various means to address that too. You can have `packages:
> /anywhere/onyourdisk` or `packages: http://somewhere.else/tar.gz in your
> cabal.project. Or you can have `source-repository-packages` for accessing
> remot
cabal-install has various means to address that too. You can have
`packages: /anywhere/onyourdisk` or `packages:
http://somewhere.else/tar.gz in your cabal.project. Or you can have
`source-repository-packages` for accessing remote git repositories. Or
you can setup
https://cabal.readthedocs.io
I agree and believe cabal v2-install has regressed from v1-install. My use
case is I'm a hobbyist who writes small programs. I assume there are
learners working outside a university class who are in a similar situation.
Even experienced developers like Richard Eisenberg seem to agree, from
https://
On Tue, Jul 09, 2024 at 01:06:02PM -0400, amindfv--- via ghc-devs wrote:
> [...]I've talked to quite a lot of people who miss the old days of `cabal
> install`-ing a package (particularly if it requires tweaking flags) [...]
Forgot to mention an additional common workflow issue: having pre-instal
On Tue, Jul 09, 2024 at 05:07:07PM +0300, Oleg Grenrus wrote:
>
> On 9.7.2024 16.35, Simon Peyton Jones wrote:
> > Would it be possible to support the simple story above, as well?
>
> TL;DR the GHC developers (e.g. you, richard, sebastian) are virtually the
> only group of people who want to invo
One other alternative is to use a cabal script. You can simply add a multiline
comment to your haskell files:
{- cabal:
build-depends: base, primitive, hashtables
-}
Then you can run the file with ‘cabal run T25064.hs’, or you can add a shebang
at the top of the file and make it executable:
#!
You can also `cabal init -n` to get a minimal cabal file, then `cabal repl
-b primitive` or whatever.
On Tue, Jul 9, 2024 at 10:12 AM Oleg Grenrus wrote:
>
> On 9.7.2024 15.23, Sebastian Graf wrote:
> > I can't simply pass `-fforce-recomp -ddump-simpl -O`
>
> You can, `cabal build --ghc-options=
On 9.7.2024 15.23, Sebastian Graf wrote:
I can't simply pass `-fforce-recomp -ddump-simpl -O`
You can, `cabal build --ghc-options= "-fforce-recomp -ddump-simpl -O"`
should work (though it applies to all packages).
> and remember all the fields that need to be set. (
`cabal init` is your fr
On 9.7.2024 15.23, Sebastian Graf wrote:
I can't simply pass `-fforce-recomp -ddump-simpl -O`
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
On 9.7.2024 16.35, Simon Peyton Jones wrote:
Would it be possible to support the simple story above, as well?
TL;DR the GHC developers (e.g. you, richard, sebastian) are virtually
the only group of people who want to invoke GHC manually, from your POV
the story might seem simple, but in gran
On 9.7.2024 16.35, Simon Peyton Jones wrote:
Would it be possible to support the simple story above, as well?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> I think Simon has a point. I really do not enjoy creating a new throwaway
> project for every small reproducer I want to test.
My (clearly faulty) mental model is this.
- I have a particular stage2 compiler, say $(GHC). Maybe built in my
build tree, maybe installed.
- If I say `$(G
Hi Simon, Hi Matt,
I think Simon has a point. I really do not enjoy creating a new throwaway
project for every small reproducer I want to test.
A cabal project means that I can't simply pass `-fforce-recomp -ddump-simpl
-O` to a GHC invocation, for example.
Instead I have to create a cabal file an
`cabal install --lib` is very hard to use properly. I would advise against it.
It is much easier to create a simple cabal project and use normal
cabal build commands. I packaged things in a repo for you.
https://github.com/mpickering/t25064
```
cabal build -w ghc-9.6.2 (fails)
cabal build -w /pa
Friends
I'm trying to repro #25064 with my development build of GHC. The test case
depends on packages `primitive` and `hashtables`. So I try this (see
below).
Alas, apparently after the `cabal install`, it can't find Prelude.
What should I do? I tried removing the "environments" file, whatev
21 matches
Mail list logo
