[gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-<phase>-all callbacks

[gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-<phase>-all callbacks

[Greg Turner]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: 004-multilib-phase-all.patch --]
[-- Type: text/x-patch, Size: 1969 bytes --]

This patch adds multilib_src_{configure,compile,test}_all
callbacks, analogous to the existing multilib_src_install_all
callback.

--- 003-in-source-doc/multilib-minimal.eclass	2013-12-03 02:45:19.428664959 -0800
+++ 004-multilib-phase-all/multilib-minimal.eclass	2013-12-03 02:54:40.045335905 -0800
@@ -86,6 +86,20 @@
 # as out-of-tree builds will not be building in the same directory as
 # the configure script.
 #
+# Non-abi-specific functionality is accomodated by an additional
+# set of callbacks, the multilib_<phase>_all functions.
+#
+# multilib_<phase>_all is called once only, after the per-ABI
+# multilib_src_<phase> functions complete, with BUILD_DIR and
+# the current working directory set to the same values as they
+# were when multilib-minimal_<phase> was invoked.
+# mutilib_src_configure is an exception; it runs before the
+# per-ABI configure steps.  Consumers may also implement their
+# own phase functions, and invoke multilib-minimal_<phase>
+# directly; doing so is mostly equivalent to
+# implementing multilib_src_<phase>_all, although it may result
+# in more confusing code.
+#
 # EAPI >= 4 is required by multilib minimial, as without it,
 # the ${MULTILIB_USEDEP} variable cannot be correctly implemented.
 #
@@ -144,6 +158,9 @@ multilib-minimal_src_configure() {
 		popd >/dev/null || die
 	}
 
+	if declare -f multilib_src_configure_all > /dev/null ; then
+		multilib_src_configure_all
+	fi
 	multilib_foreach_abi multilib-minimal_abi_src_configure
 }
 
@@ -163,6 +180,9 @@ multilib-minimal_src_compile() {
 	}
 
 	multilib_foreach_abi multilib-minimal_abi_src_compile
+	if declare -f multilib_src_compile_all > /dev/null ; then
+		multilib_src_compile_all
+	fi
 }
 
 multilib-minimal_src_test() {
@@ -181,6 +201,9 @@ multilib-minimal_src_test() {
 	}
 
 	multilib_foreach_abi multilib-minimal_abi_src_test
+	if declare -f multilib_src_test_all >/dev/null ; then
+		multilib_src_test_all
+	fi
 }
 
 multilib-minimal_src_install() {

Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-<phase>-all callbacks

[hasufell]

I'd actually consider to remove all "*_all" phases since you can achive
the same via:

src_install() {
	multilib-minimal_src_install
	generic install crap || die
}

and have more control over the call order.

But then again that will change behavior. So I am not sure about this
feature.

Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-<phase>-all callbacks

[Ulrich Mueller]

>>>>> On Wed, 11 Dec 2013, hasufell  wrote:

> I'd actually consider to remove all "*_all" phases since you can achive
> the same via:

> src_install() {
> 	multilib-minimal_src_install
> 	generic install crap || die
> }

> and have more control over the call order.

It's not completely equivalent: In the above code the einstalldocs
function will be called from multilib-minimal_src_install, whereas
with multilib_src_install_all it won't be called.

Is there actually a need for *_all, apart from the src_install phase?

Ulrich

Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-<phase>-all callbacks

[hasufell]

On 12/11/2013 10:47 PM, Ulrich Mueller wrote:
>>>>>> On Wed, 11 Dec 2013, hasufell  wrote:
> 
>> I'd actually consider to remove all "*_all" phases since you can achive
>> the same via:
> 
>> src_install() {
>> 	multilib-minimal_src_install
>> 	generic install crap || die
>> }
> 
>> and have more control over the call order.
> 
> It's not completely equivalent: In the above code the einstalldocs
> function will be called from multilib-minimal_src_install, whereas
> with multilib_src_install_all it won't be called.
> 
> Is there actually a need for *_all, apart from the src_install phase?
> 
> Ulrich
> 

I personally don't feel like it. But yeah... src_install was a bit
special, so that's why I did that.

What do the other multilib people think about it?

Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-<phase>-all callbacks

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

Dnia 2013-12-11, o godz. 13:18:54
Greg Turner <gmt@malth.us> napisał(a):

> This patch adds multilib_src_{configure,compile,test}_all
> callbacks, analogous to the existing multilib_src_install_all
> callback.

No real benefit in having those. They will introduce more confusion
because -- as hasufell pointed out -- you can do the same without those.

src_install() is special because:

a) it has default doc install. Others don't have default non-ABI stuff
to do.

b) it's quite common.

Playing similarly with src_compile() is not really beneficial. You can
achieve almost everything you need with either
'if multilib_build_binaries' conditionals or overriding generic
src_compile().

Also, next time, please keep all your mails in a single thread.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] some multilib-minimal enhancements [4/6]: ubiquitous multilib-<phase>-all callbacks

[Greg Turner]

On Wed, Dec 11, 2013 at 2:40 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> This patch adds multilib_src_{configure,compile,test}_all
>> callbacks, analogous to the existing multilib_src_install_all
>> callback.
>
> No real benefit in having those.

There is no fundamental semantic benefit I can think of; indeed, as
pointed out above, the "portage-standard"
phase-function-implementation-override +
direct-invocation-of-overridden-phase-function recipe has slightly
greater semantic power.  However, subjectively speaking, I feel that
using the multilib_<phase>_all callbacks make for cleaner and easier
to follow code.  My thinking was that providing two ways to achieve
the same thing should be harmless -- ebuild authors are, after all,
coding bash scripts to run in a UNIX-like environment, so hopefully
they are comfortable choosing between multiple-ways-to-do-it :)

However, I'm not so attached to this patch that I'd put up a big fight
over it; my overlay doesn't use them, and they are, strictly-speaking,
superfluous.

-gmt