| 1 |
Brian Harring wrote: |
| 2 |
> categorization is a bit whonky in a few spots- |
| 3 |
|
| 4 |
I won't fight that. It was pretty hard to categorize functions that I've |
| 5 |
never really noticed before ;) |
| 6 |
|
| 7 |
>> Debugging: |
| 8 |
>> register_die_hook() |
| 9 |
> |
| 10 |
> ebuild specific func, while debugging, it's not ebuild.sh debugging. |
| 11 |
> |
| 12 |
>> diefunc() |
| 13 |
>> dump_trace() |
| 14 |
> |
| 15 |
> these are general utility, not debugging. |
| 16 |
|
| 17 |
Where would you stick them? 'die' to 'ebuild helpers' and 'dump_trace' |
| 18 |
to 'internals'? |
| 19 |
|
| 20 |
>> Action functions: |
| 21 |
>> dyn_setup() |
| 22 |
>> dyn_unpack() |
| 23 |
>> dyn_clean() |
| 24 |
>> dyn_compile() |
| 25 |
>> dyn_test() |
| 26 |
>> dyn_install() |
| 27 |
>> dyn_preinst() |
| 28 |
>> dyn_help() |
| 29 |
>> |
| 30 |
>> Abort handlers: |
| 31 |
>> abort_handler() |
| 32 |
>> abort_compile() |
| 33 |
>> abort_unpack() |
| 34 |
>> abort_test() |
| 35 |
>> abort_install() |
| 36 |
>> killparent() |
| 37 |
> |
| 38 |
> internal is a better label. |
| 39 |
|
| 40 |
Well, that stuff under 'Abort handlers:' which I accidentally indented |
| 41 |
was intended to go in an own file. However, seeing the list this way, it |
| 42 |
might be better to stick them in the same one, which the label internal. |
| 43 |
Could also put the 'Internal helpers' there as they are really short anyway. |
| 44 |
|
| 45 |
> has is missing also... |
| 46 |
|
| 47 |
Well, has* is already in isolated-functions.sh. I've thought about |
| 48 |
killing that and moving the functions to the appropriate sections, but I |
| 49 |
was not sure whether isolated-functions.sh was sourced from different |
| 50 |
places too so that I simply put it off for the moment. If it's not |
| 51 |
sourced otherwise, I'd certainly move the functions there too. |
| 52 |
|
| 53 |
> If you're going to try breaking the beast up, suggest you go the step |
| 54 |
> further and break up what must be supplied from the ebuild.sh |
| 55 |
> implementation, and what is bound to the ebuild's environment. |
| 56 |
> |
| 57 |
> |
| 58 |
>> Internal eclass functions: |
| 59 |
>> newdepend() |
| 60 |
>> newrdepend() |
| 61 |
>> newpdepend() |
| 62 |
>> do_newdepend() |
| 63 |
> |
| 64 |
> These aren't eclass functions- usable without involving eclasses. |
| 65 |
> inherit ought to be in internal eclass functions also (yes it's user |
| 66 |
> visible, but it's also ebuild.sh implementation specific). |
| 67 |
|
| 68 |
Where to put them, then? |
| 69 |
|
| 70 |
>> I moved them into own files within a subdir in bin/, called modules, and |
| 71 |
>> source these files at the right time, so that nothing changes |
| 72 |
>> functionality wise. The global scope code I left untouched, except for a |
| 73 |
>> bunch of exports that set sane defaults for the do*/new* helpers. |
| 74 |
>> |
| 75 |
>> This cuts down ebuild.sh to 403 lines, which makes it far more readable, |
| 76 |
>> IMO. |
| 77 |
|
| 78 |
> Except there are now magic vars hidden away in submodules. If trying |
| 79 |
> to seperate it into seperate blocks, document 'em. |
| 80 |
|
| 81 |
Uhm, how would that documentation part work? What exactly do you want |
| 82 |
documented? (What do "it" and "'em" refer to?) |
| 83 |
|
| 84 |
About the magic vars.. I wasn't sure either whether putting the defaults |
| 85 |
into the modules was a good idea. I thought it would be good because |
| 86 |
they are not used anywhere else (didn't check), but I can just as well |
| 87 |
stick them back into ebuild.sh. |
| 88 |
|
| 89 |
>> I also set all the functions that aren't meant to be overridden by saved |
| 90 |
>> env, profile bashrc, portage bashrc or ebuilds/eclasses readonly. |
| 91 |
> |
| 92 |
> Don't think much thought was put into this tbh- use* and has* (all but |
| 93 |
> useq and hasq basically) are bound to the ebuild environment. |
| 94 |
|
| 95 |
This is actually true. |
| 96 |
|
| 97 |
> Why? Because they got mangled transitioning from 2.0.50 2.0.51, for |
| 98 |
> the ebuild to function properly it needs to use the original func from |
| 99 |
> the environment, not what the ebuild.sh implementation tries to force. |
| 100 |
> |
| 101 |
> Identified all of them that are affected by this? |
| 102 |
|
| 103 |
Well, as it stands now, all variables except the sandbox related ones |
| 104 |
are defined after env & bashrc are sourced and before the ebuild is |
| 105 |
sourced. That means that the env can't override them, which means that |
| 106 |
they are considered implementation specific in the current |
| 107 |
implementation. I agree that consideration is nonsense, though ;) |
| 108 |
|
| 109 |
So, to address the problem: What functions are bound to the ebuild |
| 110 |
rather than ebuild.sh? |
| 111 |
|
| 112 |
Beside {use,has}{,v} I don't know any. |
| 113 |
|
| 114 |
> Further, all of these are still overridable by *bashrc and env. |
| 115 |
|
| 116 |
How? |
| 117 |
|
| 118 |
> Actually it doesn't fail sourcing. |
| 119 |
|
| 120 |
Yeah, my bad. But you'd get a nice error message at least ;) |
| 121 |
|
| 122 |
> Drop the readonly crap; it's not actually blocking anything, just |
| 123 |
> attempting to catch non real issues; in the process, it actually is a |
| 124 |
> step in the wrong direction. |
| 125 |
|
| 126 |
I will drop it for now, but I would like to know the answers to above |
| 127 |
questions nevertheless. |
| 128 |
|
| 129 |
> Reordering is a bit arbitrary, but fine. Attempted env changes, would |
| 130 |
> avoid those. |
| 131 |
|
| 132 |
My primary goal is to cut down ebuild.sh to a managable size. I don't |
| 133 |
see how that can be solved with a different env handling, tbh. |
| 134 |
|
| 135 |
-- |
| 136 |
Kind Regards, |
| 137 |
|
| 138 |
Simon Stelling |
| 139 |
Gentoo/AMD64 developer |
| 140 |
-- |
| 141 |
gentoo-portage-dev@g.o mailing list |
Archives