Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] multiple inclusion protection with eclasses
Date: Thu, 08 Dec 2011 23:43:59
In Reply to: [gentoo-dev] multiple inclusion protection with eclasses by Mike Frysinger
On Thu, Dec 8, 2011 at 2:24 PM, Mike Frysinger <vapier@g.o> wrote:
> ferringb did some tests and found that doing multiple inclusion protection in > eclasses gets us some nice speed ups.  it isn't nearly as nice as if we had a > way of skipping the `source` altogether, but that that would require PMS/tree > changes.  the change i'm proposing can be implemented $now and should work > with all versions.  PMS extensions can thus be discussed in parallel. > > simply put, it's the same thing as doing standard #ifdef logic in headers to > protect against multiple inclusion errors.  on to the example: > > --- autotools.eclass > +++ autotools.eclass > @@ -10,6 +10,9 @@ >  # This eclass is for safely handling autotooled software packages that need >  # regenerate their build scripts.  All functions will abort in case of > > +if [[ ${___ECLASS_ONCE_AUTOTOOLS} != "recur -_+^+_- spank" ]] ; then > +___ECLASS_ONCE_AUTOTOOLS="recur -_+^+_- spank" > +
Not to rain on your parade; but is that the value you are sticking with? -A
>  inherit eutils libtool > >  # @ECLASS-VARIABLE: WANT_AUTOCONF > @@ -399,3 +402,5 @@ > >        echo $include_opts >  } > + > +fi > > this assumes that the eclass in question isn't doing something weird.  for > example, if you had an ebuild today that did: >        inherit eutils >        epatch() { die erp; } >        inherit eutils > > that local epatch() would get reset by the eutils inherit.  but i can't see > any ebuild having a valid reason for doing things like this, so screw 'em. > > i plan on implementing this in the eclasses i generally look over.  i don't > plan on doing it for all eclasses since i'm not familiar with them. > -mike


Subject Author
Re: [gentoo-dev] multiple inclusion protection with eclasses Mike Frysinger <vapier@g.o>