Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib

[Greg Turner <gmt@malth.us>]

On Thu, May 2, 2013 at 5:26 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Hi,
>
> I've thought for a bit and got the conclusion that the best solution
> for quite an irritating syntax of autotools-multilib is to use
> sub-phase functions.

Sorry for the delayed response, but having been playing with this
stuff lately, and I'd like to state for the record that I
whole-heartedly endorse this product and/or service.

>   autotools_configure()
>   autotools_install()
>   autotools_install_all()

I like that you manage to avoid syntax like:

  autotools_multilib_${phase}_${applicability-specifier}_${etc}...

:)

The name of the game is to get from where we are now, to where we want
to be (presumably, a future in which we can rm -rf
${PORTDIR}/app-emulation/emul-linux-x86-*), with a minimum of
repetitive and/or difficult retrofit labor.

Ideally, to multilib-retrofit an ebuild, the ebuild-repair-person
would just chop up the code a bit, and indicate to the framework which
snippets pertain to which ABI's or are ABI-independent.

We're nowhere near that now.  As you suggest, the problem is that
there's no way to "hook" any per-ABI script code into the
autotools-multilib phase functions without copy pasting the whole
boilerplate, which shrinks the value-proposition of autotools-multilib
(vs. direct inheritance to multilib-build) down to almost nothing.

All but the most simple pre-USE_EXPAND-abi-ebuilds have snippets of
script code that want to run on a per-ABI basis, often inconveniently
interspersed between src_prepare() and src_configure(), and there is
no low-effort way to wedge that code into the autotools-multilib
framework as implemented.

Often, there is some clever substitution that can be made to bridge
this feature-gap -- but by now the ebuild-repair-person is well into
"investigating/thinking deeply/drawing-board" mode, precisely where he
doesn't want to find himself if he's trying to quickly blow through a
deeply-entangled batch of 50 or 100 ebuilds requiring simultaneous
retrofitting.

> While this seems rather cosmetic...

It's not just a cosmetic problem.  ... but, a brief diversion about
aesthetics: I think, in ebuild-writing, there's a fine line between
cosmetically fucked and just plain fucked.  Likewise, the converse
also holds: an aesthetically blessed ebuild is probably blessed for
developers, bugzilla worker-bees, and end-users (gentoo sysadmins)
alike.

So, in short, cosmetic improvements are good and intrinsically
important.  Furthermore, the term "cosmetic" has connotations of
"ineffectual": that is not the case here, there are real practical
problems being solved -- your proposal ENABLES the
ebuild-repair-person to shuffle around code in a seemingly trivial
manner, but that's NOT an option with the current implementation,
instead the ebuild-repair-person must struggle against the limitations
of the framework (in addition to figuring out whatever true semantic
change is required by the retrofit).

Anyhow, meanwhile, back on planet Earth...

> The sub-phases without '_all' suffix are run inside BUILD_DIR, and
> repeated for each multilib ABI. The sub-phases with '_all' are always
> run only once, and inside S.

It's clearly a move in the right direction.  New choke points would
probably reveal themselves once we were freed from the tyranny of
constantly typing in the same code over and over :)

I do think "all" vs. "" is dsylexia-inducing and should be changed... perhaps:

at_${phase}_abi: per-abi steps (i.e., probably in per-abi ${BUILD_DIR})
at_${phase}: global steps (i.e., in ${S})

s/at/autotools/ obv.... or just leave it!  short==good here.

Anyhow, those really are trivial semantic matters.

I also think your proposal could go a bit further in the ability to
slice-and-dice the sub-phase functions.  For example, there might be
uses for granularity like:

at_${phase}: as before

at_${phase}_all: as before

at_${phase}_${ABI}: single-abi-specific stuff executed before
at_${phase}, i.e., platform-specific configure tweaks

at_${phase}_best: stuff that needs to happen in ${BUILD_DIR}, but
should only happen for DEFAULT_ABI, i.e.:, compile documentation from
source, full emake installs to deploy unwrapped header files and
/usr/share/doc stuff, etc.

Cross-compile support might suggest a couple of additional sub-phases
(i.e.: a sub-phase to generate ${CBUILD}-targeted intermediate tools
(perhaps only during cross-compiles, but I really wish somehow that
could be coded just once, tagged, and the framework could decide
whether to do anything unusual with it based on context.

> What are your thoughts? The patch is sent in reply to this mail.

Just saw your message that you are abandoning this proposal due to
lack of interest.  I think the lack of comments is not particularly
surprising.  How many people are actively getting their hands dirty
attempting to mass-retrofit ebuilds for USE_EXPAND abi-based multilib?
 I'd wager you're the only one, unless you want to count me over the
last 24 hours or so but I'm just dabbling and will probably lose
interest.

In other words, probably you are the only person in a position to see
what the requirements are.  If you are concerned about building stuff
with no "eyeballs" / feedback, then put them in new eclasses instead
of fixing the old ones (it's 'prolly better for back-compatibility to
do so anyhow).  But I'm 100% convinced you're on the right track
because I was about to start building what you described myself (and
I'm /never/ wrong! hahaha, ok, far from it, but as they say, "even if
I do say so myself...")

-gmt