[gentoo-dev] check-reqs conditionals

[gentoo-dev] check-reqs conditionals

[Ciaran McCreesh]

[-- Attachment #1.1: Type: text/plain, Size: 1087 bytes --]

For those of you who don't know, check-reqs is an eclass that is
occasionally used by a few packages that have ludicrously high build
requirements. Typical examples have included anything using Haskell (the
programming language with built-in memory leaks!) and certain C++
template metaprogamming voodoo.

Currently it just exports a single function that will warn (or die,
based upon user preference) if the build requirements aren't met. There
has been a request for a clean way of handling packages that can be
built in two different ways that give the same end result (typical
example is use of a really slow but low memory requiring algorithm vs a
fast but memory intensive algorithm when building data tables).

How does something like the attached look? (Yes, it's using old-school
[ rather than [[, since the rest of the eclass is written that way. I
might switch the whole thing over at some point.)

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: check-reqs-conditional.patch --]
[-- Type: text/x-patch; name=check-reqs-conditional.patch, Size: 1605 bytes --]

Index: check-reqs.eclass
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v
retrieving revision 1.4
diff -u -r1.4 check-reqs.eclass
--- check-reqs.eclass	6 Jul 2005 20:23:20 -0000	1.4
+++ check-reqs.eclass	11 Feb 2006 22:35:14 -0000
@@ -39,6 +39,10 @@
 #     check_reqs
 # }
 #
+# Alternatively, the check_reqs_conditional function can be used to carry out
+# alternate actions (e.g. using a much slower but far less memory intensive
+# build option that gives the same end result).
+#
 # You should *not* override the user's CHECKREQS_ACTION setting, nor should you
 # attempt to provide a value if it is unset. Note that the environment variables
 # are used rather than parameters for a few reasons:
@@ -84,6 +88,23 @@
 	fi
 }
 
+check_reqs_conditional() {
+	[ -n "$1" ] && die "Usage: check_reqs"
+
+	export CHECKREQS_NEED_SLEEP="" CHECKREQS_NEED_DIE=""
+	if [ "$CHECKREQS_ACTION" != "ignore" ] ; then
+		[ -n "$CHECKREQS_MEMORY" ] && check_build_memory
+		[ -n "$CHECKREQS_DISK_BUILD" ] && check_build_disk \
+			"${PORTAGE_TMPDIR}" "\${PORTAGE_TMPDIR}" "${CHECKREQS_DISK_BUILD}"
+		[ -n "$CHECKREQS_DISK_USR" ] && check_build_disk \
+			"${ROOT}/usr"  "\${ROOT}/usr" "${CHECKREQS_DISK_USR}"
+		[ -n "$CHECKREQS_DISK_VAR" ] && check_build_disk \
+			"${ROOT}/var"  "\${ROOT}/var" "${CHECKREQS_DISK_VAR}"
+	fi
+
+	[ -z "${CHECKREQS_NEED_SLEEP}" ] && [ -z "${CHECKREQS_NEED_DIE}" ]
+}
+
 # internal use only!
 check_build_memory() {
 	[ -n "$1" ] && die "Usage: check_build_memory"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] check-reqs conditionals

[Duncan Coutts]

On Sat, 2006-02-11 at 22:42 +0000, Ciaran McCreesh wrote:
> For those of you who don't know, check-reqs is an eclass that is
> occasionally used by a few packages that have ludicrously high build
> requirements. Typical examples have included anything using Haskell (the
> programming language with built-in memory leaks!) and certain C++
> template metaprogamming voodoo.
> 
> Currently it just exports a single function that will warn (or die,
> based upon user preference) if the build requirements aren't met. There
> has been a request for a clean way of handling packages that can be
> built in two different ways that give the same end result (typical
> example is use of a really slow but low memory requiring algorithm vs a
> fast but memory intensive algorithm when building data tables).
> 
> How does something like the attached look? (Yes, it's using old-school
> [ rather than [[, since the rest of the eclass is written that way. I
> might switch the whole thing over at some point.)
> 

Thanks Ciaran, this looks great.

I've tested it with the dev-lang/ghc ebuild and it looks like it fits
our needs. This will help us fix bug #74346.

In the ghc ebuild I'll be using it like so:

+ # The SplitObjs feature doesn't work on several arches and it makes
+ # 'ar' take loads of RAM:
+ CHECKREQS_MEMORY="200"
+ if use alpha || use ppc || use ppc64 || use sparc; then
+   echo "SplitObjs=NO" >> mk/build.mk
+ elif ! check_reqs_conditional; then
+   einfo "Turning off ghc's 'Split Objs' feature because this machine"
+   einfo "does not have enough RAM for it. This will have the effect"
+   einfo "of making binaries produced by ghc considerably larger."
+   echo "SplitObjs=NO" >> mk/build.mk
+ fi

-- 
Duncan Coutts : Gentoo Developer (Haskell herd team lead)
email         : dcoutts at gentoo dot org

-- 
gentoo-dev@gentoo.org mailing list