Petteri Räty kirjoitti: > Usually it's best that ebuild variables follow the order that is in > skel.ebuild. So know we should decide where to place EAPI. I suggest we > put it it after LICENSE as that's where the more technical stuff like > SLOT starts. Attached a patch for skel.ebuild. > > Regards, > Petteri >
The predominant options seems to be before inherit so let's go with that then. Will post more details on eclass stuff once I get further with java stuff. 00:31 < Betelgeuse> zmedico: ping 01:02 < zmedico> Betelgeuse: pong 01:03 < Betelgeuse> zmedico: Haven't seen your thoughts on EAPI place in ebuild 01:05 < zmedico> I'd say the ebuild should define it before the inherit 01:05 < zmedico> that's the simplest and safest thing to do 01:05 < Betelgeuse> zmedico: ok so I would test for EAPI=1 then in java eclasses? 01:05 < Betelgeuse> zmedico: And maybe write eapi.eclass for testing EAPI version 01:06 < Betelgeuse> zmedico: eapi 1 && <do stuff> etc 01:06 < Betelgeuse> If I only need one function then perhaps add it to eutils 01:06 < zmedico> sure 01:06 < zmedico> yeah Regards, Petteri
Index: skel.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/skel.ebuild,v retrieving revision 1.42 diff -u -r1.42 skel.ebuild --- skel.ebuild 1 Jan 2007 12:18:17 -0000 1.42 +++ skel.ebuild 12 Nov 2007 23:09:35 -0000 @@ -11,6 +11,11 @@ # will be committed to cvs, the details on that line will be automatically # generated to contain the correct data. +# The EAPI variable tells the ebuild format in use. +# Defaults to 0 if not specified. See current PMS draft for more details. +# Eclasses will test for this variable if they need to use EAPI > 0 features. +EAPI=1 + # inherit lists eclasses to inherit functions from. Almost all ebuilds should # inherit eutils, as a large amount of important functionality has been # moved there. For example, the $(get_libdir) mentioned below wont work
signature.asc
Description: OpenPGP digital signature
