Re: Review for cabal.port.mk

I'll have to look more closely, but I have a few concerns.

On Sat, Oct 03, 2020 at 11:03:43PM -0700, Greg Steuck wrote:
> MASTER_SITES0 = https://hackage.haskell.org/package/
That's a minor one.
This sets a precedent of hijacking a MASTER_SITESn for a specific module.
I don't think it's a big concern because cabal is somewhat isolated.
We'll deal with that if we must.

> DIST_SUBDIR ?= hackage
>
> # The .cabal files are explicitly copied over the ones extracted from
> # archives by the normal extraction rules.
> EXTRACT_CASES += *.cabal) ;;

I'm not fond of this solution to the PKGSTEM issue.
I would prefer that you would reconstitute DISTNAME from MODCABAL variables
exactly like stuff is done for github

> MODCABAL_HACKAGE_NAME = ${DISTNAME:C,-[0-9.]*$,,}
> MODCABAL_HACKAGE_VERSION = ${DISTNAME:C,.*-([0-9.]*)$,\1,}
and I think those variables might be a bit long, though very descriptive
what's wrong with MODCABAL_STEM and MODCABAL_VERSION ?


> .if !target(do-build)
> do-build:
> @${_MODCABAL_BUILD_TARGET}
> .endif
>
> .if !target(do-install)
> do-install:
> @${_MODCABAL_INSTALL_TARGET}
> .endif

let's think these through. _MODCABAL_{BUILD,INSTALL}_TARGET are internal
so not reusable from outside, strictly speaking.

(this is probably taken from ruby.port.mk or something similar)


If you define do-build/do-install manually, you might want to reference
these.

The reason the redirection exist is to allow non trivial build/install to
happen when several modules are combined.

in general, you may need to make these visible.