Re: Review for cabal.port.mk
Greg Steuck writes:
> Marc Espie writes:
>
>> I would prefer that you would reconstitute DISTNAME from MODCABAL variables
>> exactly like stuff is done for github.
>
> Does the diff below look like what you had in mind? I like it as the
> data becomes more structured (parsing is almost never the best choice).
> I can imagine adding some error checks to help the users.
The new version is below and at
https://github.com/blackgnezdo/ports/blob/54db9ab4253ed2ba0f294bb4e0695e2da50175aa/devel/cabal/cabal.port.mk
Another look?
# $OpenBSD$
# Module for building Haskell programs with cabal-install.
# Inspired by FreeBSD cabal.mk by Gleb Popov.
# Input variables:
#
# MODCABAL_STEM - the name of the package on hackage.
# MODCABAL_VERSION - the version of the package.
# MODCABAL_MANIFEST - hackage dependencies required by this package, tripples
#of space separate . Typically generated
#with cabal-bundler program from cabal-extras. The patch pending review
#https://github.com/phadej/cabal-extras/pull/32
# MODCABAL_DATA_DIR - data-dir from .cabal file (if the port needs the data)
#
https://cabal.readthedocs.io/en/latest/cabal-package.html#pkg-field-data-dir
# MODCABAL_REVISION - Numeric revision of .cabal file on hackage if one is
#needed on top of .cabal file contained in the .tar.gz file.
# MODCABAL_BUILD_ARGS - passed to cabal v2-build, e.g. make
MODCABAL_BUILD_ARGS=-v
#is a nice debugging aid.
# MODCABAL_FLAGS - passed to --flags= of cabal v2-build. Seemingly superflous
given
#MODCABAL_BUILD_ARGS, but it is useful to keep this value separate as it
#is used to generate the build plan and will be available without parsing.
# MODCABAL_EXECUTABLES - Executable target in .cabal file, by default uses
#the hackage package name.
#https://cabal.readthedocs.io/en/latest/cabal-package.html#executables
#
# Available output variables:
#
# MODCABAL_BUILT_EXECUTABLE_${_exe} is built for each of MODCABAL_EXECUTABLES.
#These are available for `make test` after `make build` phase.
#
# Special files:
# files/cabal.project is used automatically.
ONLY_FOR_ARCHS =i386 amd64
BUILD_DEPENDS +=devel/cabal \
lang/ghc
# Takes over :9 site for hackage. The day when we have a port using
# both Go/Rust and Hackage we'll have to resolve their common
# insistance on grabbing :9.
MASTER_SITES9 = https://hackage.haskell.org/package/
DIST_SUBDIR ?= hackage
# The .cabal files are explicitly copied over the ones extracted from
# archives by the normal extraction rules.
EXTRACT_CASES += *.cabal) ;;
DISTNAME ?= ${MODCABAL_STEM}-${MODCABAL_VERSION}
HOMEPAGE ?= ${MASTER_SITES9}${MODCABAL_STEM}
MASTER_SITES ?= ${MASTER_SITES9}${DISTNAME}/
DISTFILES ?=${DISTNAME}.tar.gz
SUBST_VARS += DISTNAME MODCABAL_STEM MODCABAL_VERSION PKGNAME
# Oftentime our port name and the executable name coincide.
MODCABAL_EXECUTABLES ?= ${MODCABAL_STEM}
# Cabal won't download anything from hackage if config file exists.
MODCABAL_post-extract = \
mkdir -p ${WRKDIR}/.cabal \
&& touch ${WRKDIR}/.cabal/config
# Some packages need an updated .cabal file from hackage to overwrite
# the one in the tar ball.
.if defined(MODCABAL_REVISION)
DISTFILES +=
${DISTNAME}_${MODCABAL_REVISION}{revision/${MODCABAL_REVISION}}.cabal
MODCABAL_post-extract += \
&& cp ${FULLDISTDIR}/${DISTNAME}_${MODCABAL_REVISION}.cabal \
${WRKSRC}/${MODCABAL_STEM}.cabal
.endif
# The dependent sources get downloaded from hackage.
.for _package _version _revision in ${MODCABAL_MANIFEST}
DISTFILES += {${_package}-${_version}/}${_package}-${_version}.tar.gz:9
. if ${_revision} > 0
DISTFILES +=
${_package}-${_version}_${_revision}{${_package}-${_version}/revision/${_revision}}.cabal:9
MODCABAL_post-extract += \
&& cp ${FULLDISTDIR}/${_package}-${_version}_${_revision}.cabal \
${WRKDIR}/${_package}-${_version}/${_package}.cabal
. endif
# References all the locally available dependencies. Ideally these
# should be command line options, tracking issue:
# https://github.com/haskell/cabal/issues/3585
MODCABAL_post-extract += \
&& echo "packages: ${WRKDIR}/${_package}-${_version}/${_package}.cabal"
>> ${WRKSRC}/cabal.project.local
.endfor # MODCABAL_MANIFEST
# Automatically copies the cabal.project file if any.
MODCABAL_post-extract += \
&& (test -f ${FILESDIR}/cabal.project \
&& cp -v ${FILESDIR}/cabal.project ${WRKSRC}; true)
# Invokes cabal with HOME set up to use .cabal directory created in
# post-extract.
_MODCABAL_CABAL = ${SETENV} ${MAKE_ENV} HOME=${WRKDIR} ${LOCALBASE}/bin/cabal
# Building a cabal package is merely an invocation of cabal v2-build.
_MODCABAL_BUILD_TARGET = \
cd ${WRKBUILD} \
&& ${_MODCABAL_CABAL} v2-build --offline --disable-benchmarks
--disable-tests \
-j${MAKE_JOBS} \
Re: Review for cabal.port.mk
Marc Espie writes:
> I would prefer that you would reconstitute DISTNAME from MODCABAL variables
> exactly like stuff is done for github.
Does the diff below look like what you had in mind? I like it as the
data becomes more structured (parsing is almost never the best choice).
I can imagine adding some error checks to help the users.
diff --git devel/alex/Makefile devel/alex/Makefile
index 77a2f8fec5f..e19050f77f0 100644
--- devel/alex/Makefile
+++ devel/alex/Makefile
@@ -2,7 +2,9 @@
COMMENT = lexical analyser generator for Haskell
-DISTNAME = alex-3.2.5
+MODCABAL_STEM = alex
+MODCABAL_VERSION = 3.2.5
+MODCABAL_DATA_DIR = data
CATEGORIES = devel
HOMEPAGE = http://www.haskell.org/alex/
@@ -13,7 +15,6 @@ PERMIT_PACKAGE = Yes
WANTLIB = c charset ffi gmp iconv m pthread util
MODULES = devel/cabal
-MODCABAL_DATA_DIR= data
LIB_DEPENDS = converters/libiconv \
devel/gmp \
diff --git devel/cabal/cabal.port.mk devel/cabal/cabal.port.mk
index 18a082206d9..3a5859266c9 100644
--- devel/cabal/cabal.port.mk
+++ devel/cabal/cabal.port.mk
@@ -3,8 +3,10 @@
# Module for building Haskell programs with cabal-install.
# Inspired by FreeBSD cabal.mk by Gleb Popov.
-# Available input variables:
+# Input variables:
#
+# MODCABAL_STEM - the name of the package on hackage.
+# MODCABAL_VERSION - the version of the package.
# MODCABAL_MANIFEST - hackage dependencies required by this package, tripples
#of space separate . Typically generated
#with cabal-bundler program from cabal-extras. The patch pending review
@@ -46,8 +48,7 @@ DIST_SUBDIR ?=hackage
# archives by the normal extraction rules.
EXTRACT_CASES += *.cabal) ;;
-MODCABAL_STEM =${DISTNAME:C,-[0-9.]*$,,}
-MODCABAL_VERSION = ${DISTNAME:C,.*-([0-9.]*)$,\1,}
+DISTNAME ?=${MODCABAL_STEM}-${MODCABAL_VERSION}
HOMEPAGE ?=${MASTER_SITES9}${MODCABAL_STEM}
MASTER_SITES ?=${MASTER_SITES9}${DISTNAME}/
DISTFILES ?= ${DISTNAME}.tar.gz
diff --git devel/happy/Makefile devel/happy/Makefile
index fbe2ab0a1bb..77b0888eba0 100644
--- devel/happy/Makefile
+++ devel/happy/Makefile
@@ -2,7 +2,10 @@
COMMENT= parser generator for Haskell
-DISTNAME= happy-1.19.12
+MODCABAL_STEM= happy
+MODCABAL_VERSION= 1.19.12
+MODCABAL_DATA_DIR= data
+
CATEGORIES=devel
HOMEPAGE= http://www.haskell.org/happy/
@@ -14,8 +17,6 @@ WANTLIB= c ffi gmp iconv m pthread
MODULES= devel/cabal
-MODCABAL_DATA_DIR= data
-
LIB_DEPENDS= converters/libiconv \
devel/gmp \
devel/libffi
Re: Review for cabal.port.mk
Thanks for the prompt review!
Marc Espie writes:
> 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.
Moved to :9 to reduce the chance of collision. Unless you believe an
indirection is warranted I'll keep it at this.
>> 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.
Is this comment about EXTRACT_CASES above or does it belong with
DISTNAME below?
> I would prefer that you would reconstitute DISTNAME from MODCABAL variables
> exactly like stuff is done for github
There's a minor tension which I'm not sure how to resolve
best. Implementing your suggestion may complicate porting the
self-hosted main binary packages that aren't published to hackage, yet
grab the dependencies there.
So far all the cases I have are hackage packages. Which means I should
follow YAGNI and implement your suggestion. I'll give it a try, but
wanted to explain why I didn't do this before.
>> 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 ?
Perfect, done.
>> .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)
I was reading bsd.port.mk(5) and port-modules(5) instead. They provided
enough guidance to not require much peeking into examples. I probably
cribbed a thing or two from ghc.port.mk, but that's fair game :)
> 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.
I erred on the side of hiding everything that I must not expose. It's
easier to expose than take away later. Do you feel I'm being too
cautious?
Thanks
Greg
Re: Review for cabal.port.mk
Sebastien Marie writes: > On Sun, Oct 04, 2020 at 09:56:22AM +0200, Marc Espie wrote: >> 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. > > just a side note. > > technically lang/rust and lang/go already do something like that, but > in a more flexible way: the number is configurable, and by default is > a high number (9) to limit conflict with possible user usage. I'm happy to switch to 9. I'm reticent to introduce a knob considering neither MODGO_MASTER_SITESN nor MODCARGO_MASTER_SITESN attracted any usage I could find. The latter has been around for 4 years. YAGNI? Thanks Greg
Re: Review for cabal.port.mk
On Sun, Oct 04, 2020 at 10:26:50AM +0200, Sebastien Marie wrote: > On Sun, Oct 04, 2020 at 09:56:22AM +0200, Marc Espie wrote: > > 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. > > just a side note. > > technically lang/rust and lang/go already do something like that, but > in a more flexible way: the number is configurable, and by default is > a high number (9) to limit conflict with possible user usage. yep... making it configurable might be a bit complex, but it should work.
Re: Review for cabal.port.mk
On Sun, Oct 04, 2020 at 09:56:22AM +0200, Marc Espie wrote: > 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. just a side note. technically lang/rust and lang/go already do something like that, but in a more flexible way: the number is configurable, and by default is a high number (9) to limit conflict with possible user usage. -- Sebastien Marie
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.
