[gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[Michał Górny]

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

Hi,

Three quick patches for review:

1. adds multilib_get_enabled_abi_pairs() as a replacement for
multilib_get_enabled_abis(). The latter returned just the value
of ${ABI}, the new function returns ${use_flag}:${ABI} pairs.

e.g.:

  multilib_get_enabled_abis: x86 amd64
  multilib_get_enabled_abi_pairs: abi_x86_32:x86 abi_x86_64:amd64

2. adds ${MULTILIB_ABI} variable to foreach loops that contains the flag
matching currently iterated ABI.

e.g.:

  ${ABI} == amd64
  ${MULTILIB_ABI} == abi_x86_64

3. deprecates multilib_for_best_abi() since having two separate
concepts of 'best ABI' and 'default ABI' is confusing, and mostly
doesn't serve any real purpose.

For improved consistency, we would like people to use multilib-minimal
and multilib_is_native_abi() tests if necessary.


I will submit the patches in replies to this mail.

-- 
Best regards,
Michał Górny

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

[gentoo-dev] [PATCH 1/3] Introduce multilib_get_enabled_abi_pairs().

[Michał Górny]

The multilib_get_enabled_abis() returns ${ABI} values only, losing the
information about USE flags. Reverse mapping of those values may
be unclear (two architectures may use the same ABI name), and therefore
the function would to do that would be unnecessarily complex.

Instead, introduce a new function that would return both the USE flags
and the matching ${ABI} value.
---
 eclass/multilib-build.eclass | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
index ddf11cc..f369923 100644
--- a/eclass/multilib-build.eclass
+++ b/eclass/multilib-build.eclass
@@ -106,6 +106,21 @@ _multilib_build_set_globals
 multilib_get_enabled_abis() {
 	debug-print-function ${FUNCNAME} "${@}"
 
+	local pairs=( $(multilib_get_enabled_abi_pairs) )
+	echo "${pairs[@]#*:}"
+}
+
+# @FUNCTION: multilib_get_enabled_abi_pairs
+# @DESCRIPTION:
+# Return the ordered list of enabled <use-flag>:<ABI> pairs
+# if multilib builds are enabled. The best (most preferred)
+# ABI will come last.
+#
+# If multilib is disabled, the default ABI will be returned
+# along with empty <use-flag>.
+multilib_get_enabled_abi_pairs() {
+	debug-print-function ${FUNCNAME} "${@}"
+
 	local abis=( $(get_all_abis) )
 
 	local abi i found
@@ -119,7 +134,7 @@ multilib_get_enabled_abis() {
 			# for the split is more complex than cheating like this
 			for m_abi in ${m_abis//,/ }; do
 				if [[ ${m_abi} == ${abi} ]] && use "${m_flag}"; then
-					echo "${abi}"
+					echo "${m_flag}:${abi}"
 					found=1
 					break 2
 				fi
@@ -134,7 +149,7 @@ multilib_get_enabled_abis() {
 
 		debug-print "${FUNCNAME}: no ABIs enabled, fallback to ${abi}"
 		debug-print "${FUNCNAME}: ABI=${ABI}, DEFAULT_ABI=${DEFAULT_ABI}"
-		echo ${abi}
+		echo ":${abi}"
 	fi
 }
 
-- 
1.9.2

[gentoo-dev] [PATCH 2/3] Export MULTILIB_ABI to obtain the USE flag for ABI.

[Michał Górny]

The main goal for this extra variable is to be able to uniquely identify
an arch+ABI pair, with equality to USE flags being an extra benefit.

Fixes: https://bugs.gentoo.org/show_bug.cgi?id=509478
---
 eclass/multilib-build.eclass | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
index f369923..4a87af6 100644
--- a/eclass/multilib-build.eclass
+++ b/eclass/multilib-build.eclass
@@ -161,7 +161,9 @@ multilib_get_enabled_abi_pairs() {
 _multilib_multibuild_wrapper() {
 	debug-print-function ${FUNCNAME} "${@}"
 
-	local ABI=${MULTIBUILD_VARIANT}
+	local ABI=${MULTIBUILD_VARIANT#*:}
+	local MULTILIB_ABI=${MULTIBUILD_VARIANT%:*}
+
 	multilib_toolchain_setup "${ABI}"
 	"${@}"
 }
@@ -178,7 +180,7 @@ _multilib_multibuild_wrapper() {
 multilib_foreach_abi() {
 	debug-print-function ${FUNCNAME} "${@}"
 
-	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abis) )
+	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abi_pairs) )
 	multibuild_foreach_variant _multilib_multibuild_wrapper "${@}"
 }
 
@@ -197,7 +199,7 @@ multilib_foreach_abi() {
 multilib_parallel_foreach_abi() {
 	debug-print-function ${FUNCNAME} "${@}"
 
-	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abis) )
+	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abi_pairs) )
 	multibuild_parallel_foreach_variant _multilib_multibuild_wrapper "${@}"
 }
 
@@ -208,7 +210,7 @@ multilib_parallel_foreach_abi() {
 multilib_for_best_abi() {
 	debug-print-function ${FUNCNAME} "${@}"
 
-	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abis) )
+	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abi_pairs) )
 
 	multibuild_for_best_variant _multilib_multibuild_wrapper "${@}"
 }
@@ -262,7 +264,7 @@ multilib_check_headers() {
 multilib_copy_sources() {
 	debug-print-function ${FUNCNAME} "${@}"
 
-	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abis) )
+	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abi_pairs) )
 	multibuild_copy_sources
 }
 
-- 
1.9.2

[gentoo-dev] [PATCH 3/3] Deprecate multilib_for_best_abi().

[Michał Górny]

This was planned for a while. The concept of 'best' and 'native' that
are not always the same ABI is confusing and mostly unnecessary.
Additionally, we prefer people using multilib-minimal phases rather than
multilib_for* functions.
---
 eclass/multilib-build.eclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
index 4a87af6..de6c27b 100644
--- a/eclass/multilib-build.eclass
+++ b/eclass/multilib-build.eclass
@@ -210,6 +210,9 @@ multilib_parallel_foreach_abi() {
 multilib_for_best_abi() {
 	debug-print-function ${FUNCNAME} "${@}"
 
+	eqawarn "QA warning: multilib_for_best_abi() function is deprecated and should"
+	eqawarn "not be used. The multilib_is_native_abi() check may be used instead."
+
 	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abi_pairs) )
 
 	multibuild_for_best_variant _multilib_multibuild_wrapper "${@}"
-- 
1.9.2

Re: [gentoo-dev] [PATCH 3/3] Deprecate multilib_for_best_abi().

[hasufell]

Michał Górny:
> This was planned for a while. The concept of 'best' and 'native' that
> are not always the same ABI is confusing and mostly unnecessary.
> Additionally, we prefer people using multilib-minimal phases rather than
> multilib_for* functions.
> ---
>  eclass/multilib-build.eclass | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
> index 4a87af6..de6c27b 100644
> --- a/eclass/multilib-build.eclass
> +++ b/eclass/multilib-build.eclass
> @@ -210,6 +210,9 @@ multilib_parallel_foreach_abi() {
>  multilib_for_best_abi() {
>  	debug-print-function ${FUNCNAME} "${@}"
>  
> +	eqawarn "QA warning: multilib_for_best_abi() function is deprecated and should"
> +	eqawarn "not be used. The multilib_is_native_abi() check may be used instead."
> +
>  	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abi_pairs) )
>  
>  	multibuild_for_best_variant _multilib_multibuild_wrapper "${@}"
> 

I wonder if it makes sense to add a repoman warning for these kind of
deprecations? Not sure if many people read the post-emerge output. By
experience, not so many.

Re: [gentoo-dev] [PATCH 3/3] Deprecate multilib_for_best_abi().

[Michał Górny]

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

Dnia 2014-05-05, o godz. 17:26:14
hasufell <hasufell@gentoo.org> napisał(a):

> Michał Górny:
> > This was planned for a while. The concept of 'best' and 'native' that
> > are not always the same ABI is confusing and mostly unnecessary.
> > Additionally, we prefer people using multilib-minimal phases rather than
> > multilib_for* functions.
> > ---
> >  eclass/multilib-build.eclass | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
> > index 4a87af6..de6c27b 100644
> > --- a/eclass/multilib-build.eclass
> > +++ b/eclass/multilib-build.eclass
> > @@ -210,6 +210,9 @@ multilib_parallel_foreach_abi() {
> >  multilib_for_best_abi() {
> >  	debug-print-function ${FUNCNAME} "${@}"
> >  
> > +	eqawarn "QA warning: multilib_for_best_abi() function is deprecated and should"
> > +	eqawarn "not be used. The multilib_is_native_abi() check may be used instead."
> > +
> >  	local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abi_pairs) )
> >  
> >  	multibuild_for_best_variant _multilib_multibuild_wrapper "${@}"
> > 
> 
> I wonder if it makes sense to add a repoman warning for these kind of
> deprecations? Not sure if many people read the post-emerge output. By
> experience, not so many.

I was thinking about that wrt multilib_build_binaries but it seems that
in current repoman code, the check for each function is treated
as a separate test. I'd rather wait till someone adds a single test
with a list for deprecated functions instead :).

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[Ulrich Mueller]

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

>>>>> On Mon, 5 May 2014, Michał Górny wrote:

> Three quick patches for review:

> 1. adds multilib_get_enabled_abi_pairs() as a replacement for
> multilib_get_enabled_abis(). The latter returned just the value
> of ${ABI}, the new function returns ${use_flag}:${ABI} pairs.

> e.g.:

>   multilib_get_enabled_abis: x86 amd64
>   multilib_get_enabled_abi_pairs: abi_x86_32:x86 abi_x86_64:amd64

These will get included in the pathname of the build dir, right?

If yes, are you sure that all upstream build systems can cope with
the colon in path names? I'd rather suggest to stay within the POSIX
portable filename character set (i.e. [A-Za-z0-9._-]).

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[Michał Górny]

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

Dnia 2014-05-05, o godz. 11:02:33
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Mon, 5 May 2014, Michał Górny wrote:
> 
> > Three quick patches for review:
> 
> > 1. adds multilib_get_enabled_abi_pairs() as a replacement for
> > multilib_get_enabled_abis(). The latter returned just the value
> > of ${ABI}, the new function returns ${use_flag}:${ABI} pairs.
> 
> > e.g.:
> 
> >   multilib_get_enabled_abis: x86 amd64
> >   multilib_get_enabled_abi_pairs: abi_x86_32:x86 abi_x86_64:amd64
> 
> These will get included in the pathname of the build dir, right?
> 
> If yes, are you sure that all upstream build systems can cope with
> the colon in path names? I'd rather suggest to stay within the POSIX
> portable filename character set (i.e. [A-Za-z0-9._-]).

I was wondering about that in the morning but thought mostly of Windows
and decided we don't need to care. But now that I think of it, I can
think of ${PATH} and similar colon-separated variables.

I should probably use '.' then, since it's both more distinct than '-'
and disallowed in USE flags. Possibly stripping ':*' in multibuild could
result in more elegant paths but I don't want to introduce any other
special rules to follow.

Which makes me think that I need to check that no ebuild assumes
${S%/}-${ABI}.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/05/14 04:29 AM, Michał Górny wrote:

> 3. deprecates multilib_for_best_abi() since having two separate 
> concepts of 'best ABI' and 'default ABI' is confusing, and mostly 
> doesn't serve any real purpose.
> 
> For improved consistency, we would like people to use
> multilib-minimal and multilib_is_native_abi() tests if necessary.
> 
> 
> I will submit the patches in replies to this mail.
> 

multilib_for_best_abi was introduced to deprecate
multilib_is_native_abi though, aren't we going backwards?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlNnkOwACgkQ2ugaI38ACPDY/QD7BobGgWFjbKt7FAfHd1aRFoOx
01drmn7eg50Pz6ICLY0A/29oqW21Qocf5rKLhLiE+cfRBFRoLow/4To6Gq0pFa5B
=we6c
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[Michał Górny]

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

Dnia 2014-05-05, o godz. 09:23:56
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 05/05/14 04:29 AM, Michał Górny wrote:
> 
> > 3. deprecates multilib_for_best_abi() since having two separate 
> > concepts of 'best ABI' and 'default ABI' is confusing, and mostly 
> > doesn't serve any real purpose.
> > 
> > For improved consistency, we would like people to use
> > multilib-minimal and multilib_is_native_abi() tests if necessary.
> > 
> > 
> > I will submit the patches in replies to this mail.
> > 
> 
> multilib_for_best_abi was introduced to deprecate
> multilib_is_native_abi though, aren't we going backwards?

Honestly, I don't remember why it was introduced. I just checked
the commit message and relevant mails, and it's all quite laconic.
It was introduced as part of multibuild_for_best_variant(), and that
benefited mostly distutils-r1 for its *_all() phases.

I think multilib_for_best_abi() was mostly intended to help getting
autotools-multilib to work properly. Now it is built on top of
multilib-minimal, and people are encouraged to redefine the multilib_*
phases rather than try to hack on top of 'autotools-utils_src_compile'
and stuff. This makes most of multilib_for_best_abi() irrelevant.

So, I don't think we are really going backwards here. We've changed
direction over the past year. We've seen what caught better and I'm
mostly trying to make things simpler. As part of that, I'd like to
remove redundant APIs and focus on supporting one best-supported
interface for multilib. At the point, multilib-minimal seems to be
the way forward.

Do you agree with me on this? Do you have another ideas?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/05/14 01:42 PM, Michał Górny wrote:
> Dnia 2014-05-05, o godz. 09:23:56 Ian Stakenvicius <axs@gentoo.org>
> napisał(a):
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 05/05/14 04:29 AM, Michał Górny wrote:
>> 
>>> 3. deprecates multilib_for_best_abi() since having two separate
>>>  concepts of 'best ABI' and 'default ABI' is confusing, and
>>> mostly doesn't serve any real purpose.
>>> 
>>> For improved consistency, we would like people to use 
>>> multilib-minimal and multilib_is_native_abi() tests if
>>> necessary.
>>> 
>>> 
>>> I will submit the patches in replies to this mail.
>>> 
>> 
>> multilib_for_best_abi was introduced to deprecate 
>> multilib_is_native_abi though, aren't we going backwards?
> 
> Honestly, I don't remember why it was introduced. I just checked 
> the commit message and relevant mails, and it's all quite laconic. 
> It was introduced as part of multibuild_for_best_variant(), and
> that benefited mostly distutils-r1 for its *_all() phases.
> 
> I think multilib_for_best_abi() was mostly intended to help
> getting autotools-multilib to work properly. Now it is built on top
> of multilib-minimal, and people are encouraged to redefine the
> multilib_* phases rather than try to hack on top of
> 'autotools-utils_src_compile' and stuff. This makes most of
> multilib_for_best_abi() irrelevant.
> 
> So, I don't think we are really going backwards here. We've
> changed direction over the past year. We've seen what caught better
> and I'm mostly trying to make things simpler. As part of that, I'd
> like to remove redundant APIs and focus on supporting one
> best-supported interface for multilib. At the point,
> multilib-minimal seems to be the way forward.
> 
> Do you agree with me on this? Do you have another ideas?
> 

Nope, this makes sense now.  I have a sneaky suspicion that my memory
had some cross-talk between multilib_for_best_abi and
multilib_build_binaries, too...  if multilib_for_best_abi was always
based on multilib_is_native_abi, then I expect it will be fine to
deprecate it.






-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlNn2LEACgkQ2ugaI38ACPDddAEAthcqIbx9/4TBM0rfqlDnXdk7
ZeFzOkHlUYv7xNGBoFMBALZItkBcJVO8VNQ1bvUYVf+j8W98JWmUt6MBgZdiZZm2
=a6pm
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[Michał Górny]

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

Dnia 2014-05-05, o godz. 10:29:12
Michał Górny <mgorny@gentoo.org> napisał(a):

> 2. adds ${MULTILIB_ABI} variable to foreach loops that contains the flag
> matching currently iterated ABI.
> 
> e.g.:
> 
>   ${ABI} == amd64
>   ${MULTILIB_ABI} == abi_x86_64

Committed as MULTILIB_ABI_FLAG to avoid collision with ${MULTILIB_ABI}
used by multilib portage & confusion with ${MULTILIB_ABIS}.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCHES] multilib-build.eclass: getting 'long' ABI value & deprecating multilib_for_best_abi()

[Bertrand Jacquin]

On 2014-05-23 09:55, Michał Górny wrote:
> Dnia 2014-05-05, o godz. 10:29:12
> Michał Górny <mgorny@gentoo.org> napisał(a):
> 
>> 2. adds ${MULTILIB_ABI} variable to foreach loops that contains the 
>> flag
>> matching currently iterated ABI.
>> 
>> e.g.:
>> 
>>   ${ABI} == amd64
>>   ${MULTILIB_ABI} == abi_x86_64
> 
> Committed as MULTILIB_ABI_FLAG to avoid collision with ${MULTILIB_ABI}
> used by multilib portage & confusion with ${MULTILIB_ABIS}.

Thank you Michał !