On Mon, 23 Feb 2009 08:43:09 -0700 Steve Dibb wrote: > Richard Freeman wrote: > > I still don't see why we need to be encoding metadata in filenames. > > PERL doesn't care what a file extension is, python doesn't care, > > bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even > > ld-linux.so doesn't care. I'm sure that in at least some of these > > cases they end up parsing parts of the file twice - once to figure > > out what it is, and the second time to actually handle it. I'm > > actually hard pressed to think of any unix-based software that uses > > the filename to store a mandatory file format versioning specifier > > of some kind. $ ls /usr/lib > I have to admit I'm in the same camp with Richard, and don't > understand the necessity. I'm also opposed to creating arbitrary > suffixes to the ebuild extension, for cosmetic and compatibility > reasons. > > Plus, I don't really grasp the whole "we have to source the whole > ebuild to know the EAPI version" argument. It's one variable, in one > line. Can't a simple parser get that and go from there? Not really. Let's play Guess the EAPI. :o 1. ----- EAPI=1 ---- 2. (with myeclass.eclass containing EAPI=2) ----- EAPI=1 inherit myeclass ----- 3. (with myeclass.eclass containing EAPI=2) ----- EAPI=5 inherit myeclass ----- 1. 1 (simple enough) 2. 2 (because myeclass.eclass sets EAPI=2) 3. 5 (inherit was changed in EAPI 5 to not overwrite ${EAPI} if already set in an ebuild) So you see, it's not as easy as a grep command. You need to source the ebuild to know how things like inherit will affect the environment. And without knowing the EAPI, you don't know which version of inherit to call. (i hope i have this right. feel free to call me names if i don't) -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662