Haskell ports: cabal v2-build?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Haskell ports: cabal v2-build?

Greg Steuck
While looking at Haskell binary ports, a couple of approaches seem
possible.

1) Embed Haskell libraries into ports, build binaries from them.
2) Build binaries with `cabal new-build`

The status quo is #1. This has a few benefits: it exists, libraries
are reused by multiple ports reducing build costs. There are
drawbacks: the ports tree contains a duplicate (and sometimes
inconsistent) specification of Hackage information. Because of this,
upgrades are a big pain and there's a version of DLL (cabal) hell in
that a single compatible library version needs to be chosen for all
ports.

An alternative is #2. Many hs-* library ports could go away by making
each binary port (e.g. darcs, shellcheck) build their own library
dependencies in its sandbox. This will reduce maintenance costs and
avoid any possibility of version conflicts. There are drawbacks: it
doesn't exist, the same library will get built for each binary using
it. We also won't be able to switch to a completely clean #2. Some
ports (e.g. xmonad) use Haskell build as a configuration mechanism. We
still need to provide a subset of ports-embedded libraries in the
style of #1.

If we are to keep doing #1, we should automate maintenance as much as
possible. portgen is an option and so is building a port targeting
version of cabal2bazel (once brought up to date)

If the majority of OpenBSD users only care about using the binaries, I
believe we will serve them better by doing #2 for the binary providing
ports.

Some unknowns apply to design #2:
  * how well we can specify the Hackage snapshot
  * how hermetic we can make it (force tarball fetching to happen
    before running `cabal new-build`)

Thoughts?

Thanks
Greg

P.S. Ports with Haskell binaries:
% for i in $(</tmp/all-hs ); do grep '^@bin' $i/pkg/PLIST*>/dev/null &&
echo $i; done
devel/alex
devel/cabal-install
devel/cpphs
devel/darcs
devel/gmc4cc
devel/happy
devel/hasktags
devel/shellcheck
games/hedgewars
net/hpodder
textproc/hs-HaXml
x11/xmonad
x11/xmobar

All ports (including sub-packages) dependent on ghc:
sqlite> select count(fullpkgpath) from ports where build_depends like
'%ghc%';
123

--
nest.cx is Gmail hosted, use PGP:
https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0
Reply | Threaded
Open this post in threaded view
|

Re: Haskell ports: cabal v2-build?

Greg Steuck
Hello,

I'm looking for strong negative reactions (if any) to this proposal so I
don't waste any time.

On Sat, Jun 8, 2019 at 9:27 PM Greg Steuck <[hidden email]> wrote:
> While looking at Haskell binary ports, a couple of approaches seem
> possible.
>
> 1) Embed Haskell libraries into ports, build binaries from them.
> 2) Build binaries with `cabal new-build`

I'm reviving this thread to see if this is a plausible path forward for
ghc-8.10 upgrade.
The new information that I learned since I wrote the original[1] was that
FreeBSD already
implemented the cabal new-build route (before I even wrote the original
email):
https://github.com/freebsd/freebsd-ports/commit/0f5d99f9175dc8876140c7b098358d51223c7f5d

The main takeaway here is that the approach is workable and we can learn
from their experience.
In particular, custom xmonad configurations require local rebuilding which
isn't hard, but does
mean a beefier machine is needed.

I'm keeping a running log of my learnings:
https://github.com/blackgnezdo/ports/issues/3

Thanks
Greg

[1]
https://openbsdmailbox.blogspot.com/2019/06/haskell-ports-cabal-v2-build.html
--
nest.cx is Gmail hosted, use PGP:
https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0