Gentoo Logo
Gentoo Spaceship

Installation:
Gentoo Handbook
Installation Docs

Documentation:
Home
Listing
About Gentoo
Philosophy
Social Contract

Resources:
Bug Tracker
Developer List
Discussion Forums
Gentoo BitTorrents
Gentoo Linux Enhancement Proposals
IRC Channels
Mailing Lists
Mirrors
Name and Logo Guidelines
Online Package Database
Security Announcements
Staffing Needs
Supporting Vendors
View our CVS

Graphics:
Logos and themes
Icons
ScreenShots

Miscellaneous Resources:
Gentoo Linux Store
Gentoo-hosted projects
IBM dW/Intel article archive




List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Brian Harring <ferringb@...>
Subject: Re: Re: EAPI-2 and src_configure in eclasses
Date: Tue, 7 Oct 2008 20:21:28 -0700
On Tue, Oct 07, 2008 at 05:07:21PM +0100, Steve Long wrote:
> Ciaran McCreesh wrote:
> 
> > On Sun, 5 Oct 2008 17:38:11 +0200
> > Ulrich Mueller <ulm@g.o> wrote:
> >> > By the way, do we really want to special case eapi-2 in every
> >> > eclass ? That's lot of code duplication and will get even worse
> >> > when we'll reach eapi-42. That would have been cool to have a pm
> >> > function that tells "has my eapi foo support" but that sort of
> >> > bites its tail that way.
> >> 
> >> Hm, what about:
> >> [ "$(type -t src_configure)" == function ] && EXPORT_FUNCTIONS
> >> src_configure
> >> 
> >> Or is this too fragile or trying to be too clever?
> > 
> > It's illegal, according to PMS. It also won't work with Paludis, since
> > phase function definitions aren't made available until just before that
> > phase executes (there is a reason for this -- it provides us with a way
> > of identifying whether a package has a particular phase or not).
> > 
> That seems a bit implementation-specific; how one alternative package
> manager generates that metadata isn't important (though it does seem odd
> that you think it has to be done at that point) nor should it get in the
> way.

Actually both alternative PM's do this now (>=pkgcore-0.4.7.9), 
although in pkgcore's case the default phase functions are installed 
after sourcing rather then at the time of invocation.

Long term, this is the correct way to go imo- the downside to it is 
that a common sourcing env needs be defined at some point (newdepend, 
newrdepend, etc) to avoid any question of what's available.

~brian
Attachment:
pgpYq2KjaCorJ.pgp (PGP signature)
References:
EAPI-2 and src_configure in eclasses
-- Ulrich Mueller
Re: EAPI-2 and src_configure in eclasses
-- Ciaran McCreesh
Re: EAPI-2 and src_configure in eclasses
-- Alexis Ballier
Re: EAPI-2 and src_configure in eclasses
-- Ulrich Mueller
Re: EAPI-2 and src_configure in eclasses
-- Ciaran McCreesh
Re: EAPI-2 and src_configure in eclasses
-- Steve Long
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
[project] Re: Re: EAPI-2 and src_configure in eclasses
Next by thread:
Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
Previous by date:
Re: Changing doc use flag on gtk-doc packages to gtk-doc-rebuild or something else
Next by date:
Re: Re: Testing is not a valid reason to package.mask


Updated Jun 17, 2009

Donate to support our development efforts.

Gentoo Centric Hosting: vr.org

VR Hosted

Tek Alchemy

Tek Alchemy

SevenL.net

SevenL.net

php|architect

php|architect

Copyright 2001-2007 Gentoo Foundation, Inc. Questions, Comments? Email www@gentoo.org.