[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merge wip-haskell?

From: Timothy Sample
Subject: Re: merge wip-haskell?
Date: Sun, 09 Aug 2020 00:29:35 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi Ricardo,

Ricardo Wurmus <> writes:

> Timothy Sample <> writes:
>> Also, it looks like “wip-haskell-updates” is no longer being built by
>> the CI infrastructure.  Since the branch triggers a rebuild of all the
>> Haskell packages, it should be built before merging, right?
> Yes, I’ll rebase it on top of “master” and add the specification to
> well before the merge.


I just pushed “wip-haskell-updates-2” which integrates my work from
<>.  I left the original branch intact
to make it easy to compare.

Basically, where you remove the “--extra-include-dirs” and
“--extra-lib-dirs” arguments in configure, I preserve them and hide them
behind a build system argument.  To do this, I split up the commit where
you remove them into a refactor commit (where you remove “append” and
just use quasiquoting), and a commit that removes “--bindir”.  My commit
goes in the middle.

Then, I remove the commits that fix up ghc-hslua, ghc-libyaml, and
ghc-zlib, as that’s handled in my commit.

The only other thing I did was move the shared libraries commit sooner,
since it needs to be in place for the static output commit to work (at
least nothing would build for me without it).

With respect to the substance of your changes, I think the results are
worth the ugliness!  Keeping “ghc-pandoc” as the “normal” package and
using “pandoc” for the statically linked one makes sense if feasible.
Unfortunately, I don’t know of a better way to get all the static
libraries in place.

It would be nice if there was a way to get similar improvements without
static linking, but I imagine it would be tough.  I’m not suggesting
anything for now, but maybe we could split the GHC package so that other
packages could reference the “base” library (125M) without referencing
the “ghc” and “Cabal” libraries (818M).  Ultimately it would be nice to
have a more general solution.

In the meantime, I think that this is fine.

-- Tim

reply via email to

[Prev in Thread] Current Thread [Next in Thread]