Hi Ricardo, Ricardo Wurmus <rek...@elephly.net> writes:
> Timothy Sample <samp...@ngyro.com> 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 > ci.guix.gnu.org well before the merge. Excellent. I just pushed “wip-haskell-updates-2” which integrates my work from <https://issues.guix.gnu.org/39309>. 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