Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
Hi Kili,
On 06/17/16 01:32, Matthias Kilian wrote:
> Hi,
>
> On Thu, Jun 16, 2016 at 05:34:09PM -0500, Aaron Poffenberger wrote:
>> Thanks to your suggestion and a pointer to the Java "maven" thread by
>> Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
>> the cabal dependencies using DISTFILES.
>>
>> I tested building pandoc with networking disabled. It works.
>
> I don't think this cabal sandbox model is suitable for ports in any
> way. What will happen if we enable shared libraries for ghc (which,
> according to some mails from Karel Gardas, should be possible with
> ghc-8)? Where will those libraries be end up in ${LOCALBASE}?
For the most part, the value of sandboxing the build will be to build
stand-alone executables like pandoc. Once built, the bits from
MODGHC_CABAL_SANDBOX aren't further referenced and may be safely deleted.
>
> And do you think it's useful to have several different versions of
> the same haskell library sprinkled over the system?
>
> In the pandoc port, MODGHC_CABAL_PKGS even contains library/version
> combinations we already have as separate ports.
The point of specifying the versions is those are the exact combination
of pkgs the cabal resolver determined will work together based on the
constraints from the pandoc.cabal file *and* the libraries I required in
RUN_DEPENDS-lib.
The versions are also required since BULK(8) builds don't allow network
access. As I understand it, everything has to be downloaded into
FULLDISTDIR before configure begins.
>
> Sorry, but I'm not a big fan of this concept.
>
> BTW, the pandoc-lib subpackage doesn't make any sense unless it
> does not depend on any of the cabal packages listed in MODGHC_CABAL_PKGS,
> because the libraries provided by those packages would be missing
> (they aren't installed). It also wouldn't install properly because
> PLIST-lib is wrong.
You're right about the -lib pkg. It won't work as currently ported. The
chief aim of sandboxing was to make standalone binaries possible without
a recursive porting effort for all the dependencies.
There are three possible resolutions: 1) don't include the -lib in the
package, 2) install the dependencies in
${LOCALBASE}/lib/ghc/pandoc-1.17.1 and update register.sh, or 3) scrap
the sandboxing idea altogether.
I don't like the last idea: scrapping sandboxing. pandoc has huge, unmet
dependency lists. And even if one were to recursively port every missing
dependency we still might have conflicts with existing ports due to
version-requirement conflicts. This would lead to having the same pkg
ported twice but for different versions.
I'm sure you know this is why Haskell-LTS was started: to create a
stable list of pkgs that work together. Unless we're following a
specific LTS release, we will run into version conflicts at some point.
(I think following a specific LTS release would be a good idea, but
that's a conversation for another email.)
Sandboxing solves this problem, certainly for binaries. And could
resolve library conflicts if libs can have their unmet dependencies
installed in their ${LOCALBASE}/lib/pkg dir.
Cheers,
--Aaron
Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
Hi,
On Thu, Jun 16, 2016 at 05:34:09PM -0500, Aaron Poffenberger wrote:
> Thanks to your suggestion and a pointer to the Java "maven" thread by
> Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
> the cabal dependencies using DISTFILES.
>
> I tested building pandoc with networking disabled. It works.
I don't think this cabal sandbox model is suitable for ports in any
way. What will happen if we enable shared libraries for ghc (which,
according to some mails from Karel Gardas, should be possible with
ghc-8)? Where will those libraries be end up in ${LOCALBASE}?
And do you think it's useful to have several different versions of
the same haskell library sprinkled over the system?
In the pandoc port, MODGHC_CABAL_PKGS even contains library/version
combinations we already have as separate ports.
Sorry, but I'm not a big fan of this concept.
BTW, the pandoc-lib subpackage doesn't make any sense unless it
does not depend on any of the cabal packages listed in MODGHC_CABAL_PKGS,
because the libraries provided by those packages would be missing
(they aren't installed). It also wouldn't install properly because
PLIST-lib is wrong.
Ciao,
Kili
Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
On 06/16/16 17:34, Aaron Poffenberger wrote:
> On 06/15/16 07:46, Stuart Henderson wrote:
>> On 2016/06/15 07:12, Aaron Poffenberger wrote:
>>> You are right. cabal can install from a local path. Is it possible to
>>> feed a bunch of files into the process by adding them to distinfo?
>>
>> Aha: if you can list the distfiles in DISTFILES and point cabal at them
>> locally that should work.
>>
>> Fetching will be a little messy if the files are in separate subdirs
>> as I think they are on hackage, but it can be handled by using the
>> filename{url}sufx syntax in DISTFILES for them, e.g.
>> {path/to/}filename-$V.tar.gz which would be somewhat similar to what
>> devel/cargo is doing (peril-sensitive glasses advised before looking
>> at the regexp there ;)
>>
>> You can use EXTRACT_ONLY to stop ports infra from trying to unpack
>> them itself, and ${FULLDISTDIR} to get the path.
>>
> Hi Stuart,
> Thanks to your suggestion and a pointer to the Java "maven" thread by
> Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
> the cabal dependencies using DISTFILES.
>
> I tested building pandoc with networking disabled. It works.
>
> I forgot that cabal expects package repos to have a specific structure
> and manifest describing the repo. I've implemented the necessary code to
> build it. Any comments on improving that section would be welcome.
>
> I'm using symlinks between the tarballs in ${FULLDISTDIR} and the local
> cabal repo (MODGHC_CABAL_REPO).
>
> The cabal sandbox is also a local directory (MODGHC_CABAL_SANDBOX) by
> default.
>
> Of the two, MODGHC_CABAL_SANDBOX is a good candidate for sharing between
> sandboxed builds. You could create a shared repo (MODGHC_CABAL_REPO) but
> since it's just symlinks and a manifest there's not much value.
>
> N.B. to anyone who uses a shared MODGHC_CABAL_SANDBOX, read the comment
> in ghc.port.mk for instructions on proper initialization.
>
> Attached are the revised patch and example port of pandoc for testing with.
>
> --Aaron
>
Attached are the same files as before plus a patch for port-modules.5.
I documented the *sandbox* build action and added a "Defines" section to
document use of three variables that porters will need to know about to
sandbox.
I also moved the explanation of the two variables MODGHC_SETUP_CONF_ARGS
and MODGHC_SETUP_CONF_ENV from what was the final paragraph into the
"Defines" section for consistency.
--Aaron
pandoc-1.17.1.tgz
Description: Binary data
Index: ghc.port.mk
===
RCS file: /home/cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -u -r1.38 ghc.port.mk
--- ghc.port.mk 20 Jan 2016 16:08:29 - 1.38
+++ ghc.port.mk 16 Jun 2016 22:22:35 -
@@ -1,3 +1,4 @@
+#-*- mode: Makefile; tab-width: 4; -*-
# $OpenBSD: ghc.port.mk,v 1.38 2016/01/20 16:08:29 kili Exp $
# Module for Glasgow Haskell Compiler
@@ -55,7 +56,21 @@ DIST_SUBDIR ?= ghc
. if ${MODGHC_BUILD:L:Mcabal}
MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs
+. if ${MODGHC_BUILD:L:Msandbox}
+BUILD_DEPENDS += devel/cabal-install
+# Set MODGHC_CABAL_SANDBOX to system-wide value to reuse packages
+# across builds. Be sure to initialize it first.
+# mkdir -p ${MODGHC_CABAL_SANDBOX}
+# cd ${MODGHC_CABAL_SANDBOX} && cabal sandbox init --sandbox .
+MODGHC_CABAL_PKGS ?=
+MODGHC_CABAL_REPO ?= ${WRKSRC}/.local-repo
+MODGHC_CABAL_SANDBOX ?= ${WRKSRC}/.cabal-sandbox
+MODGHC_SETUP_PROG ?= ${LOCALBASE}/bin/cabal
+MODGHC_REGISTER_PROG ?= ${WRKSRC}/Setup
+. else
MODGHC_SETUP_PROG ?= ${WRKSRC}/Setup
+MODGHC_REGISTER_PROG ?= ${MODGHC_SETUP_PROG}
+. endif
MODGHC_SETUP_CONF_ARGS ?=
MODGHC_SETUP_CONF_ENV ?=
@@ -76,6 +91,56 @@ MODGHC_SETUP_CONF_ARGS += --docdir=\$$da
# Little hack to let ports still add CONFIGURE_STYLE = autoconf and go
# without a do-configure: target (some Haskell ports are built with
# Cabal but use autohell for the documentation):
+. if ${MODGHC_BUILD:L:Msandbox}
+# Build a cabal repo from downloaded packages
+. for _pkg in ${MODGHC_CABAL_PKGS}
+_ver := ${_pkg:C,.*-([0-9.]*)$,\1,}
+_name := ${_pkg:C,-[0-9.]*$,,}
+_path := ${_ver}/${_name}
+_tgz := ${_pkg}.tar.gz
+MODGHC_CABAL_PATHS +:= ${_path}
+MODGHC_CABAL_LINK_CMDS +:= "ln -sf ${FULLDISTDIR}/${_pkg}/${_tgz} ${_path}"
+MODGHC_CABAL_EXTRACT_CMDS +:="tar xzf ${_path}/${_tgz} ${_pkg}/${_name}.cabal"
+MODGHC_CABAL_MOVE_CMDS +:= "mv ${_pkg}/${_name}.cabal ${_path}"
+MODGHC_CABAL_RMDIR_CMDS +:= "rmdir ${_pkg}"
+. endfor
+
+MODCABAL_configure = \
+ mkdir -p ${MODGHC_CABAL_REPO}/packages && \
+ cd ${MODGHC_CABAL_REPO}/packages && \
+ for s in ${MODGHC_CABAL_PATHS}; do \
+ mkdir -p "$$s"; \
+ done && \
+ for s in ${MODGHC_CABAL_LINK_CMDS}; do \
+ $$s; \
+ done && \
+ for s in ${MODGHC_CABAL_EXTRACT_CMDS}; do \
+ $$s; \
+ done && \
+ for s in ${MODGHC_CABAL_MOVE_CMDS}; do \
+ $$s; \
+ done && \
+ for s in ${MODGHC_CABAL_RMDIR_CMDS}; do \
+ $$s; \
+ done && \
+ find . -type f -name
Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
On 06/16/16 17:34, Aaron Poffenberger wrote:
> On 06/15/16 07:46, Stuart Henderson wrote:
>> On 2016/06/15 07:12, Aaron Poffenberger wrote:
>>> You are right. cabal can install from a local path. Is it possible to
>>> feed a bunch of files into the process by adding them to distinfo?
>>
>> Aha: if you can list the distfiles in DISTFILES and point cabal at them
>> locally that should work.
>>
>> Fetching will be a little messy if the files are in separate subdirs
>> as I think they are on hackage, but it can be handled by using the
>> filename{url}sufx syntax in DISTFILES for them, e.g.
>> {path/to/}filename-$V.tar.gz which would be somewhat similar to what
>> devel/cargo is doing (peril-sensitive glasses advised before looking
>> at the regexp there ;)
>>
>> You can use EXTRACT_ONLY to stop ports infra from trying to unpack
>> them itself, and ${FULLDISTDIR} to get the path.
>>
> Hi Stuart,
> Thanks to your suggestion and a pointer to the Java "maven" thread by
> Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
> the cabal dependencies using DISTFILES.
>
> I tested building pandoc with networking disabled. It works.
>
> I forgot that cabal expects package repos to have a specific structure
> and manifest describing the repo. I've implemented the necessary code to
> build it. Any comments on improving that section would be welcome.
>
> I'm using symlinks between the tarballs in ${FULLDISTDIR} and the local
> cabal repo (MODGHC_CABAL_REPO).
>
> The cabal sandbox is also a local directory (MODGHC_CABAL_SANDBOX) by
> default.
>
> Of the two, MODGHC_CABAL_SANDBOX is a good candidate for sharing between
> sandboxed builds. You could create a shared repo (MODGHC_CABAL_REPO) but
> since it's just symlinks and a manifest there's not much value.
>
> N.B. to anyone who uses a shared MODGHC_CABAL_SANDBOX, read the comment
> in ghc.port.mk for instructions on proper initialization.
>
> Attached are the revised patch and example port of pandoc for testing with.
>
> --Aaron
>
Realized on the way home I'll need to modify port-modules(5) for this to
be a complete solution. I'll start on that next.
--Aaron
Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
On 06/15/16 07:46, Stuart Henderson wrote:
> On 2016/06/15 07:12, Aaron Poffenberger wrote:
>> You are right. cabal can install from a local path. Is it possible to
>> feed a bunch of files into the process by adding them to distinfo?
>
> Aha: if you can list the distfiles in DISTFILES and point cabal at them
> locally that should work.
>
> Fetching will be a little messy if the files are in separate subdirs
> as I think they are on hackage, but it can be handled by using the
> filename{url}sufx syntax in DISTFILES for them, e.g.
> {path/to/}filename-$V.tar.gz which would be somewhat similar to what
> devel/cargo is doing (peril-sensitive glasses advised before looking
> at the regexp there ;)
>
> You can use EXTRACT_ONLY to stop ports infra from trying to unpack
> them itself, and ${FULLDISTDIR} to get the path.
>
Hi Stuart,
Thanks to your suggestion and a pointer to the Java "maven" thread by
Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
the cabal dependencies using DISTFILES.
I tested building pandoc with networking disabled. It works.
I forgot that cabal expects package repos to have a specific structure
and manifest describing the repo. I've implemented the necessary code to
build it. Any comments on improving that section would be welcome.
I'm using symlinks between the tarballs in ${FULLDISTDIR} and the local
cabal repo (MODGHC_CABAL_REPO).
The cabal sandbox is also a local directory (MODGHC_CABAL_SANDBOX) by
default.
Of the two, MODGHC_CABAL_SANDBOX is a good candidate for sharing between
sandboxed builds. You could create a shared repo (MODGHC_CABAL_REPO) but
since it's just symlinks and a manifest there's not much value.
N.B. to anyone who uses a shared MODGHC_CABAL_SANDBOX, read the comment
in ghc.port.mk for instructions on proper initialization.
Attached are the revised patch and example port of pandoc for testing with.
--Aaron
pandoc-1.17.1.tgz
Description: Binary data
Index: ghc.port.mk
===
RCS file: /home/cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -u -r1.38 ghc.port.mk
--- ghc.port.mk 20 Jan 2016 16:08:29 - 1.38
+++ ghc.port.mk 16 Jun 2016 22:22:35 -
@@ -1,3 +1,4 @@
+#-*- mode: Makefile; tab-width: 4; -*-
# $OpenBSD: ghc.port.mk,v 1.38 2016/01/20 16:08:29 kili Exp $
# Module for Glasgow Haskell Compiler
@@ -55,7 +56,21 @@ DIST_SUBDIR ?= ghc
. if ${MODGHC_BUILD:L:Mcabal}
MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs
+. if ${MODGHC_BUILD:L:Msandbox}
+BUILD_DEPENDS += devel/cabal-install
+# Set MODGHC_CABAL_SANDBOX to system-wide value to reuse packages
+# across builds. Be sure to initialize it first.
+# mkdir -p ${MODGHC_CABAL_SANDBOX}
+# cd ${MODGHC_CABAL_SANDBOX} && cabal sandbox init --sandbox .
+MODGHC_CABAL_PKGS ?=
+MODGHC_CABAL_REPO ?= ${WRKSRC}/.local-repo
+MODGHC_CABAL_SANDBOX ?= ${WRKSRC}/.cabal-sandbox
+MODGHC_SETUP_PROG ?= ${LOCALBASE}/bin/cabal
+MODGHC_REGISTER_PROG ?= ${WRKSRC}/Setup
+. else
MODGHC_SETUP_PROG ?= ${WRKSRC}/Setup
+MODGHC_REGISTER_PROG ?= ${MODGHC_SETUP_PROG}
+. endif
MODGHC_SETUP_CONF_ARGS ?=
MODGHC_SETUP_CONF_ENV ?=
@@ -76,6 +91,56 @@ MODGHC_SETUP_CONF_ARGS += --docdir=\$$da
# Little hack to let ports still add CONFIGURE_STYLE = autoconf and go
# without a do-configure: target (some Haskell ports are built with
# Cabal but use autohell for the documentation):
+. if ${MODGHC_BUILD:L:Msandbox}
+# Build a cabal repo from downloaded packages
+. for _pkg in ${MODGHC_CABAL_PKGS}
+_ver := ${_pkg:C,.*-([0-9.]*)$,\1,}
+_name := ${_pkg:C,-[0-9.]*$,,}
+_path := ${_ver}/${_name}
+_tgz := ${_pkg}.tar.gz
+MODGHC_CABAL_PATHS +:= ${_path}
+MODGHC_CABAL_LINK_CMDS +:= "ln -sf ${FULLDISTDIR}/${_pkg}/${_tgz} ${_path}"
+MODGHC_CABAL_EXTRACT_CMDS +:="tar xzf ${_path}/${_tgz} ${_pkg}/${_name}.cabal"
+MODGHC_CABAL_MOVE_CMDS +:= "mv ${_pkg}/${_name}.cabal ${_path}"
+MODGHC_CABAL_RMDIR_CMDS +:= "rmdir ${_pkg}"
+. endfor
+
+MODCABAL_configure = \
+ mkdir -p ${MODGHC_CABAL_REPO}/packages && \
+ cd ${MODGHC_CABAL_REPO}/packages && \
+ for s in ${MODGHC_CABAL_PATHS}; do \
+ mkdir -p "$$s"; \
+ done && \
+ for s in ${MODGHC_CABAL_LINK_CMDS}; do \
+ $$s; \
+ done && \
+ for s in ${MODGHC_CABAL_EXTRACT_CMDS}; do \
+ $$s; \
+ done && \
+ for s in ${MODGHC_CABAL_MOVE_CMDS}; do \
+ $$s; \
+ done && \
+ for s in ${MODGHC_CABAL_RMDIR_CMDS}; do \
+ $$s; \
+ done && \
+ find . -type f -name '*.cabal' >> files && \
+ tar -cf 00-index.tar -I files && \
+ rm -f files && \
+ cd ${WRKSRC} && \
+ ${MODGHC_SETUP_PROG} sandbox init --sandbox=${MODGHC_CABAL_SANDBOX} && \
+ echo "local-repo: ${MODGHC_CABAL_REPO}/packages" > cabal.config && \
+ ${MODGHC_SETUP_PROG} install --only-dependencies ${MODGHC_SETUP_CONF_ARGS} && \
+ for s in ${MODGHC_SETUP_SCRIPT}; do \
+ test -f "$$s" && \
+ ${MODGHC_BIN} --make \
+ -o ${MODGHC_REGISTER_PROG} "$$s" && \
+ break; \
+ done && \
+ cd ${WRKBUILD} && exec ${SETENV}
Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
For those interested, I added a man page called bulk(8) to ports/infrastructure recently. It does explain in some details how to setup a cluster for package building. This is *de facto* the standard you have to deal with for all ports. Official and development build clusters are built using those recommendations, and in particular, we don't intend to go back to "one user fits all" builds (if anything there will be even MORE separation in the future). There are several people already using _pbuild and _pfetch with _pbuild prevented from any interaction with the network, in close kept chroots.
Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
On 2016/06/15 07:12, Aaron Poffenberger wrote:
> You are right. cabal can install from a local path. Is it possible to
> feed a bunch of files into the process by adding them to distinfo?
Aha: if you can list the distfiles in DISTFILES and point cabal at them
locally that should work.
Fetching will be a little messy if the files are in separate subdirs
as I think they are on hackage, but it can be handled by using the
filename{url}sufx syntax in DISTFILES for them, e.g.
{path/to/}filename-$V.tar.gz which would be somewhat similar to what
devel/cargo is doing (peril-sensitive glasses advised before looking
at the regexp there ;)
You can use EXTRACT_ONLY to stop ports infra from trying to unpack
them itself, and ${FULLDISTDIR} to get the path.
Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
Hi Stuart,
On 06/15/16 06:56, Stuart Henderson wrote:
> Hi Aaron,
>
> On 2016/06/14 21:08, Aaron Poffenberger wrote:
>> Below is a patch to add cabal-sandbox support to ghc.port.mk, to build
>> Haskell package-dependencies in a sandbox.
>
> The patch got word-wrapped (you can send attachments to ports@
> if that's easiest).
Attached.
>
>> The motivation is to make porting packages with large, unmet
>> dependency-lists easier.
>
> This suggests that it's downloading during build. If I'm right then
> sorry for the bad news but unfortunately it won't work out that way,
> the only network access we permit during bulk builds is controlled
> by DPB during the fetch stage so it must be done as standard distfiles
> fetched by http/ftp and with checksums in the distinfo file.
>
>> If there's no interest or significant concerns with sandboxing, I'll
>> work on a regular port of pandoc by first porting it's dependencies.
>
> I wonder if this might be something that would be reasonable to
> handle via portgen..
>
You are right. cabal can install from a local path. Is it possible to
feed a bunch of files into the process by adding them to distinfo?
Alternatively, I had been thinking to make a portgen for Haskell. I'll
look at the code to see what's required.
Index: ghc.port.mk
===
RCS file: /home/cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -u -r1.38 ghc.port.mk
--- ghc.port.mk 20 Jan 2016 16:08:29 - 1.38
+++ ghc.port.mk 15 Jun 2016 01:36:51 -
@@ -1,3 +1,4 @@
+#-*- mode: Makefile; tab-width: 4; -*-
# $OpenBSD: ghc.port.mk,v 1.38 2016/01/20 16:08:29 kili Exp $
# Module for Glasgow Haskell Compiler
@@ -55,7 +56,19 @@ DIST_SUBDIR ?= ghc
. if ${MODGHC_BUILD:L:Mcabal}
MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs
+. if ${MODGHC_BUILD:L:Msandbox}
+BUILD_DEPENDS += devel/cabal-install
+# Set MODGHC_SANDBOX to system-wide value to reuse packages
+# across builds. Be sure to initialize it first.
+# mkdir -p ${MODGHC_SANDBOX}
+# cd ${MODGHC_SANDBOX} && cabal sandbox init --sandbox .
+MODGHC_SANDBOX ?= ${WRKSRC}/.cabal-sandbox
+MODGHC_SETUP_PROG ?= ${LOCALBASE}/bin/cabal
+MODGHC_REGISTER_PROG ?= ${WRKSRC}/Setup
+. else
MODGHC_SETUP_PROG ?= ${WRKSRC}/Setup
+MODGHC_REGISTER_PROG ?= ${MODGHC_SETUP_PROG}
+. endif
MODGHC_SETUP_CONF_ARGS ?=
MODGHC_SETUP_CONF_ENV ?=
@@ -76,6 +89,23 @@ MODGHC_SETUP_CONF_ARGS += --docdir=\$$da
# Little hack to let ports still add CONFIGURE_STYLE = autoconf and go
# without a do-configure: target (some Haskell ports are built with
# Cabal but use autohell for the documentation):
+. if ${MODGHC_BUILD:L:Msandbox}
+MODCABAL_configure = \
+ cd ${WRKSRC} && \
+ ${MODGHC_SETUP_PROG} sandbox init --sandbox=${MODGHC_SANDBOX} && \
+ ${MODGHC_SETUP_PROG} update && \
+ ${MODGHC_SETUP_PROG} install --only-dependencies ${MODGHC_SETUP_CONF_ARGS} && \
+ for s in ${MODGHC_SETUP_SCRIPT}; do \
+ test -f "$$s" && \
+ ${MODGHC_BIN} --make \
+ -o ${MODGHC_REGISTER_PROG} "$$s" && \
+ break; \
+ done && \
+ cd ${WRKBUILD} && exec ${SETENV} ${MAKE_ENV} ${MODGHC_SETUP_CONF_ENV} \
+ ${MODGHC_SETUP_PROG} \
+ configure -v -g -O --prefix=${PREFIX} \
+ ${MODGHC_SETUP_CONF_ARGS}
+. else
MODCABAL_configure = \
cd ${WRKSRC} && \
for s in ${MODGHC_SETUP_SCRIPT}; do \
@@ -88,6 +118,7 @@ MODCABAL_configure = \
${MODGHC_SETUP_PROG} \
configure -v -g -O --prefix=${PREFIX} \
${MODGHC_SETUP_CONF_ARGS}
+. endif
CONFIGURE_STYLE += CABAL
@@ -102,9 +133,9 @@ MODGHC_BUILD_TARGET += \
. if ${MODGHC_BUILD:L:Mregister}
MODGHC_BUILD_TARGET += \
;cd ${WRKBUILD} && ${SETENV} ${MAKE_ENV} \
- ${MODGHC_SETUP_PROG} register --gen-script; \
+ ${MODGHC_REGISTER_PROG} register --gen-script; \
cd ${WRKBUILD} && ${SETENV} ${MAKE_ENV} \
- ${MODGHC_SETUP_PROG} unregister --gen-script
+ ${MODGHC_REGISTER_PROG} unregister --gen-script
. endif
MODGHC_INSTALL_TARGET = \
Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
Hi Aaron, On 2016/06/14 21:08, Aaron Poffenberger wrote: > Below is a patch to add cabal-sandbox support to ghc.port.mk, to build > Haskell package-dependencies in a sandbox. The patch got word-wrapped (you can send attachments to ports@ if that's easiest). > The motivation is to make porting packages with large, unmet > dependency-lists easier. This suggests that it's downloading during build. If I'm right then sorry for the bad news but unfortunately it won't work out that way, the only network access we permit during bulk builds is controlled by DPB during the fetch stage so it must be done as standard distfiles fetched by http/ftp and with checksums in the distinfo file. > If there's no interest or significant concerns with sandboxing, I'll > work on a regular port of pandoc by first porting it's dependencies. I wonder if this might be something that would be reasonable to handle via portgen..
Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc
Hello ports@,
Below is a patch to add cabal-sandbox support to ghc.port.mk, to build
Haskell package-dependencies in a sandbox.
The patch adds two new variables, a MODGHC_BUILD option "sandbox" and
modifies MODCABAL_configure and MODGHC_BUILD_TARGET.
Most of the diff should be obvious. I had to add MODGHC_SETUP_PROG and
update MODGHC_BUILD_TARGET to use it when registering and unregistering
because cabal doesn't have the unregister command.
The motivation is to make porting packages with large, unmet
dependency-lists easier. converters/pandoc is an example of such a
package. I've included the port as an example of building a port using
dependencies from ports where available and sandboxing for the rest.
Sandboxing dependency builds is also helpful in cases of version conflicts.
If there's no interest or significant concerns with sandboxing, I'll
work on a regular port of pandoc by first porting it's dependencies.
--Aaron
Index: ghc.port.mk
===
RCS file: /home/cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -u -r1.38 ghc.port.mk
--- ghc.port.mk 20 Jan 2016 16:08:29 - 1.38
+++ ghc.port.mk 15 Jun 2016 01:36:51 -
@@ -1,3 +1,4 @@
+#-*- mode: Makefile; tab-width: 4; -*-
# $OpenBSD: ghc.port.mk,v 1.38 2016/01/20 16:08:29 kili Exp $
# Module for Glasgow Haskell Compiler
@@ -55,7 +56,19 @@ DIST_SUBDIR ?= ghc
. if ${MODGHC_BUILD:L:Mcabal}
MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs
+. if ${MODGHC_BUILD:L:Msandbox}
+BUILD_DEPENDS += devel/cabal-install
+# Set MODGHC_SANDBOX to system-wide value to reuse packages
+# across builds. Be sure to initialize it first.
+# mkdir -p ${MODGHC_SANDBOX}
+# cd ${MODGHC_SANDBOX} && cabal sandbox init --sandbox .
+MODGHC_SANDBOX ?= ${WRKSRC}/.cabal-sandbox
+MODGHC_SETUP_PROG ?= ${LOCALBASE}/bin/cabal
+MODGHC_REGISTER_PROG ?=${WRKSRC}/Setup
+. else
MODGHC_SETUP_PROG ?= ${WRKSRC}/Setup
+MODGHC_REGISTER_PROG ?=${MODGHC_SETUP_PROG}
+. endif
MODGHC_SETUP_CONF_ARGS ?=
MODGHC_SETUP_CONF_ENV ?=
@@ -76,6 +89,23 @@ MODGHC_SETUP_CONF_ARGS +=--docdir=\$$da
# Little hack to let ports still add CONFIGURE_STYLE = autoconf and go
# without a do-configure: target (some Haskell ports are built with
# Cabal but use autohell for the documentation):
+. if ${MODGHC_BUILD:L:Msandbox}
+MODCABAL_configure = \
+ cd ${WRKSRC} && \
+ ${MODGHC_SETUP_PROG} sandbox init --sandbox=${MODGHC_SANDBOX} && \
+ ${MODGHC_SETUP_PROG} update && \
+ ${MODGHC_SETUP_PROG} install --only-dependencies
${MODGHC_SETUP_CONF_ARGS} && \
+ for s in ${MODGHC_SETUP_SCRIPT}; do \
+ test -f "$$s" && \
+ ${MODGHC_BIN} --make \
+ -o ${MODGHC_REGISTER_PROG} "$$s" && \
+ break; \
+ done && \
+ cd ${WRKBUILD} && exec ${SETENV} ${MAKE_ENV} ${MODGHC_SETUP_CONF_ENV} \
+ ${MODGHC_SETUP_PROG} \
+ configure -v -g -O --prefix=${PREFIX} \
+ ${MODGHC_SETUP_CONF_ARGS}
+. else
MODCABAL_configure = \
cd ${WRKSRC} && \
for s in ${MODGHC_SETUP_SCRIPT}; do \
@@ -88,6 +118,7 @@ MODCABAL_configure = \
${MODGHC_SETUP_PROG} \
configure -v -g -O --prefix=${PREFIX} \
${MODGHC_SETUP_CONF_ARGS}
+. endif
CONFIGURE_STYLE += CABAL
@@ -102,9 +133,9 @@ MODGHC_BUILD_TARGET += \
. if ${MODGHC_BUILD:L:Mregister}
MODGHC_BUILD_TARGET += \
;cd ${WRKBUILD} && ${SETENV} ${MAKE_ENV} \
- ${MODGHC_SETUP_PROG} register --gen-script; \
+ ${MODGHC_REGISTER_PROG} register --gen-script; \
cd ${WRKBUILD} && ${SETENV} ${MAKE_ENV} \
- ${MODGHC_SETUP_PROG} unregister --gen-script
+ ${MODGHC_REGISTER_PROG} unregister --gen-script
. endif
MODGHC_INSTALL_TARGET = \
pandoc-1.17.1.tgz
Description: Binary data
