From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KmX9L-0006cL-Ab for garchives@archives.gentoo.org; Sun, 05 Oct 2008 17:12:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 121F9E02DF; Sun, 5 Oct 2008 17:11:16 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id DE1E0E02E5 for ; Sun, 5 Oct 2008 17:11:15 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 9D54B64B59 for ; Sun, 5 Oct 2008 17:11:14 +0000 (UTC) Message-ID: <48E8F52C.7080509@gentoo.org> Date: Sun, 05 Oct 2008 10:11:08 -0700 From: Zac Medico User-Agent: Thunderbird 2.0.0.17 (X11/20080914) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EAPI-2 and src_configure in eclasses References: <18664.49886.385742.36918@a1ihome1.kph.uni-mainz.de> <20081005150727.15d307c6@googlemail.com> <20081005161546.31446f38@gentoo.org> <20081005152420.1d1e3256@googlemail.com> <20081005170740.4a067aef@gentoo.org> <20081005161716.72ef734f@googlemail.com> In-Reply-To: <20081005161716.72ef734f@googlemail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: dcc9fd14-c19d-4978-bfbe-6a8e6be598b6 X-Archives-Hash: 79c2419fbd1bc0060494637b463e1e36 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 5 Oct 2008 17:07:40 +0200 > Alexis Ballier wrote: >> Maybe eclasses should die on unknown eapi; the fact is I really hate >> the current way it's done when switching an ebuild to EAPI-2 which >> uses an eclass that exports src_compile; most eclasses don't special >> case eapi-2 yet and we end up running econf twice at best. I fear >> that'll be the same with eapi-3, eapi-4, etc. (supposing that they'll >> support src_configure too) > > There's currently no mechanism for an ebuild or eclass to 'die' in > global scope. They can call 'die' in global scope. Perhaps it's not the nicest thing to do, but it can be done. > It's something that could be available for future EAPIs without too > much difficulty, though... We discussed this for Exherbo, and decided > upon something like this: > > * Add a new metadata key called BROKENNESS. > > * Any ID with non-empty BROKENNESS is treated as being hard masked and > not unmaskable by the user, in the same way than an unknown EAPI is. > > * Add a function which can only be called in global scope that adds an > item to BROKENNESS. This does *not* prevent further sourcing. > > This one hopefully shouldn't be too hard to implement (Zac?). If people > are running into excessive difficulties with eclasses, it might be > worth doing an EAPI 3 quickly with just this addition... > Considering that they can already call 'die' in global scope I don't see it as being that urgent. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjo9SsACgkQ/ejvha5XGaOUUQCfRSaJYF3xqWfaLVfE1M5lT0Fk NDcAnikfPOu/6nnBZIXuKbUXptNIPyOP =Lpc7 -----END PGP SIGNATURE-----