OK so it turns out there were two issues at play here:
* I had `_build` as a symlink, and that's no bueno since Hadrian passes
some relative paths like `_build/../libraries` to some command lines. This
isn't ideal but is not a dealbreaker.
* It turns out Hadrian recently was broken with regar
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
Thanks a lot for the clarification Andreas.
So, the present situation is that we seem to have an implicit set of
packages that are readily available to users of ghc and ghci, but which
serve no direct goal for the end-user, and whose presence is fairly
arbitrary.
In light of the recent discu
For context, the move from xhtml to lucid2 is very much in progress, for
both haddock and hpc. The necessity to avoid too many third-party
libraries is that in its current (and very custom) setup, dependencies
are git submodules in the GHC tree. Which somewhat make sense because
these dependenc
> I think they could be statically linked. But those boot libraries don't
> change much and generally
> don't really cause us nor users pain so it seems like there is little
> reason to do so to me.
There once was a sizeable patch to Haddock to switch from xhtml to Lucid,
and it was rejected, seem
I think they could be statically linked. But those boot libraries don't
change much and generally
don't really cause us nor users pain so it seems like there is little
reason to do so to me.
> Surely the size of binaries can't be the only concern, otherwise we'd
use upx¹ on them when distributing
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
Hi devs,
I had a chat earlier today with someone and found myself unable to
explain the reason why GHC came with boot dependencies like xhtml, that
are dependencies of Haddock and HPC.
Obviously, the binaries are (haskell-)dynamically linked when
distributed, but what is the reason why haddo
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
12 matches
Mail list logo
