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 -- [email protected] mailing list
