Re: [gentoo-portage-dev] Refactoring ebuild.sh

[Brian Harring]

On Sun, Aug 27, 2006 at 10:26:28AM +0200, Simon Stelling wrote:
> Brian Harring wrote:
> >> 	diefunc()
> >> 	dump_trace()
> >
> > these are general utility, not debugging.
>
> Where would you stick them? 'die' to 'ebuild helpers' and 'dump_trace'
> to 'internals'?

util, same for hasq.

> > If you're going to try breaking the beast up, suggest you go the step
> > further and break up what must be supplied from the ebuild.sh
> > implementation, and what is bound to the ebuild's environment.
> >
> >
> >> Internal eclass functions:
> >> 	newdepend()
> >> 	newrdepend()
> >> 	newpdepend()
> >> 	do_newdepend()
> >
> > These aren't eclass functions- usable without involving eclasses.
> > inherit ought to be in internal eclass functions also (yes it's user
> > visible, but it's also ebuild.sh implementation specific).
>
> Where to put them, then?

...they're ebuild functions.  stick them with the other ebuild 
functions (use_with fex).

Personally, I think trying to seperate it up at this level is probably 
not a great idea; splitting the EAPI specific bits into seperate 
modules, yes, but when/if EAPI=1 arrives changing chunks, it's going 
to be a mess going through each module and ifdef'ing functions.


> >> I moved them into own files within a subdir in bin/, called modules, and
> >> source these files at the right time, so that nothing changes
> >> functionality wise. The global scope code I left untouched, except for a
> >> bunch of exports that set sane defaults for the do*/new* helpers.
> >>
> >> This cuts down ebuild.sh to 403 lines, which makes it far more readable,
> >> IMO.
>
> > Except there are now magic vars hidden away in submodules.  If trying
> > to seperate it into seperate blocks, document 'em.
>
> Uhm, how would that documentation part work? What exactly do you want
> documented? (What do "it" and "'em" refer to?)
>
> About the magic vars.. I wasn't sure either whether putting the defaults
> into the modules was a good idea. I thought it would be good because
> they are not used anywhere else (didn't check), but I can just as well
> stick them back into ebuild.sh.

Sticking magic vars (globals mostly, eclass_depth for example) in 
locations seperate from the functionality that uses it needs to be 
documented; moving all of the globals up to ebuild.sh means that for 
any code to reuse those modules without using ebuild.sh, it has to 
maintain it's own globals list.

So... magic vars need to stay in the module that uses them, and need 
documentating if another module relies on it; with ebuild.sh, this 
isn't an issue, everything is guranteed loaded, with submodules it's a 
bit more of an issue.


> >> I also set all the functions that aren't meant to be overridden by saved
> >> env, profile bashrc, portage bashrc or ebuilds/eclasses readonly.
> >
> > Don't think much thought was put into this tbh- use* and has* (all but
> > useq and hasq basically) are bound to the ebuild environment.
>
> This is actually true.
>
> > Why?  Because they got mangled transitioning from 2.0.50 2.0.51, for
> > the ebuild to function properly it needs to use the original func from
> > the environment, not what the ebuild.sh implementation tries to force.
> >
> > Identified all of them that are affected by this?
>
> Well, as it stands now, all variables except the sandbox related ones
> are defined after env & bashrc are sourced and before the ebuild is
> sourced. That means that the env can't override them, which means that
> they are considered implementation specific in the current
> implementation. I agree that consideration is nonsense, though ;)
>
> So, to address the problem: What functions are bound to the ebuild
> rather than ebuild.sh?
pkg_*, src_*, *opts, *into, *depend .

Basically, think of which are implementation specific (portageq) vs 
which aren't directly reliant on implementation details.  If it's not 
implementation specific, it's likely bound to the ebuild env.

> Beside {use,has}{,v} I don't know any.
>
> > Further, all of these are still overridable by *bashrc and env.
>
> How?
readonly -f .

bashrc, env, etc, all can force different definitions of functions.  

This is why ebd sets it's required functions and marks them readonly 
*before* it even goes near ebuild data; do it the other way around, 
you're not guranteeing anything.


> > Drop the readonly crap; it's not actually blocking anything, just
> > attempting to catch non real issues; in the process, it actually is a
> > step in the wrong direction.
>
> I will drop it for now, but I would like to know the answers to above
> questions nevertheless.
>
> > Reordering is a bit arbitrary, but fine.  Attempted env changes, would
> > avoid those.
>
> My primary goal is to cut down ebuild.sh to a managable size. I don't
> see how that can be solved with a different env handling, tbh.

Env handling affects the flow of the code; never said it reduces the 
total size of code though (just said don't go screwing with readonly).
~harring