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: Alexis Ballier <aballier@g.o>
Subject: Re: Re: EAPI-2 and src_configure in eclasses
Date: Thu, 9 Oct 2008 10:26:04 +0200
> I don't quite see how that deals with an eclass calling econf in its
> exported src_compile? Seems like EAPI versioning for eclasses (with
> implicit 0 only) is more what you're after for that issue (so the PM
> could suppress src_configure if src_compile is going to resolve to an
> EAPI-0 eclass function, although the inheritance stack might prove
> problematic.)

I don't know of any way for the pm to detect if the eclass supports
given eapi or not, and even less if exported src_compile will be eapi-2
aware or not.

> Having to die for an unsupported EAPI seems like the wrong approach;
> if it's not going to work the PM shouldn't source it. If it can be
> made to work by filtering certain functions, that's doable.

I tend to see dying for an unsupported eapi as eclass versioning for
the poor people but that's the only thing we can do atm afaik. For now,
all eapi are backward compatible wrt to sourcing so that's not really
an issue to source an eapi-0 eclass withing an eapi-2 ebuild. I think
there has been a discussion on eclasses vs eapi before and the outcome
was that eclasses should add hacky checks for eapi; which means to me
we'll have to adjust those hacky checks for each new eapi.

However, for now, not dying allows workarounds like:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/ogmrip/ogmrip-0.12.2.ebuild?view=markup
but I don't consider it very pretty.

> In the worst case, an ebuild switching to EAPI will require eclass
> maintenance; this is where the separation of elibs (useful code) and
> eclasses (template ebuilds) would be useful, although that needs
> versioning too.

The problem will remain for this new definition of eclasses; glad to
see you're volunteering to fix every single eclass that exports a
src_compile/unpack function for eapi-2 :)

If by template ebuilds you mean the EXPORT_FUNCTIONS line and some deps,
then I dont see the difference between eapi versioning for eclasses and
a switch/case for each eapi in the unversioned eclass. Note that "useful
code" can differ upon eapi (I'm thinking about has_version checks).

Regards,

Alexis.
Attachment:
signature.asc (PGP signature)
Replies:
Re: Re: EAPI-2 and src_configure in eclasses
-- Alec Warner
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
-- Ciaran McCreesh
Re: EAPI-2 and src_configure in eclasses
-- Alexis Ballier
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:
Re: EAPI-2 and src_configure in eclasses
Next by thread:
Re: Re: EAPI-2 and src_configure in eclasses
Previous by date:
Re: [gentoo-commits] gentoo-x86 commit in net-fs/openafs: openafs-1.4.8_pre2.ebuild
Next by date:
Re: Monthly Gentoo Council Reminder for October


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.