[gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

It is a simple eclass using autotools out-of-source builds to build
packages for multiple ABIs when multilib is supported.

Use case: xorg packages, ask Matt.
---
 gx86/eclass/autotools-multilib.eclass | 72 +++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 gx86/eclass/autotools-multilib.eclass

diff --git a/gx86/eclass/autotools-multilib.eclass b/gx86/eclass/autotools-multilib.eclass
new file mode 100644
index 0000000..1a345a1
--- /dev/null
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -0,0 +1,72 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+# @ECLASS: autotools-multilib.eclass
+# @MAINTAINER:
+# Michał Górny <mgorny@gentoo.org>
+# @BLURB: autotools-utils wrapper for multilib builds
+# @DESCRIPTION:
+# The autotools-multilib.eclass is an autotools-utils.eclass(5) wrapper
+# introducing support for building for more than one ABI (multilib).
+#
+# Inheriting this eclass sets IUSE=multilib and exports autotools-utils
+# phase function wrappers which build the package for each supported ABI
+# if the flag is enabled. Otherwise, it works like regular
+# autotools-utils.
+#
+# Note that the multilib support requires out-of-source builds to be
+# enabled. Thus, it is impossible to use AUTOTOOLS_IN_SOURCE_BUILD with
+# it.
+
+case ${EAPI:-0} in
+	2|3|4) ;;
+	*) die "EAPI=${EAPI} is not supported" ;;
+esac
+
+if [[ ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
+	die "${ECLASS}: multilib support requires out-of-source builds."
+fi
+
+inherit autotools-utils multilib
+
+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
+
+IUSE=multilib
+
+# @FUNCTION: autotools-multilib_foreach_abi
+# @USAGE: argv...
+# @DESCRIPTION:
+# If multilib support is enabled, sets the toolchain up for each
+# supported ABI along with the ABI variable and correct
+# AUTOTOOLS_BUILD_DIR, and runs the given commands with them.
+#
+# If multilib support is disabled, it just runs the commands. No setup
+# is done.
+autotools-multilib_foreach_abi() {
+	if use multilib; then
+		local ABI
+		for ABI in $(get_all_abis); do
+			multilib_toolchain_setup "${ABI}"
+			AUTOTOOLS_BUILD_DIR=${S%%/}-${ABI} "${@}"
+		done
+	else
+		"${@}"
+	fi
+}
+
+autotools-multilib_src_configure() {
+	autotools-multilib_foreach_abi autotools-utils_src_configure
+}
+
+autotools-multilib_src_compile() {
+	autotools-multilib_foreach_abi autotools-utils_src_compile
+}
+
+autotools-multilib_src_test() {
+	autotools-multilib_foreach_abi autotools-utils_src_test
+}
+
+autotools-multilib_src_install() {
+	autotools-multilib_foreach_abi autotools-utils_src_install
+}
-- 
1.7.12

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Luca Barbato]

"Michał Górny" <mgorny@gentoo.org> wrote:

>It is a simple eclass using autotools out-of-source builds to build
>packages for multiple ABIs when multilib is supported.
>
>Use case: xorg packages, ask Matt.
>---
>gx86/eclass/autotools-multilib.eclass | 72
>+++++++++++++++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
> create mode 100644 gx86/eclass/autotools-multilib.eclass
>
>diff --git a/gx86/eclass/autotools-multilib.eclass
>b/gx86/eclass/autotools-multilib.eclass
>new file mode 100644
>index 0000000..1a345a1
>--- /dev/null
>+++ b/gx86/eclass/autotools-multilib.eclass
>@@ -0,0 +1,72 @@
>+# Copyright 1999-2012 Gentoo Foundation
>+# Distributed under the terms of the GNU General Public License v2
>+# $Header: $
>+
>+# @ECLASS: autotools-multilib.eclass
>+# @MAINTAINER:
>+# Michał Górny <mgorny@gentoo.org>
>+# @BLURB: autotools-utils wrapper for multilib builds
>+# @DESCRIPTION:
>+# The autotools-multilib.eclass is an autotools-utils.eclass(5)
>wrapper
>+# introducing support for building for more than one ABI (multilib).
>+#
>+# Inheriting this eclass sets IUSE=multilib and exports
>autotools-utils
>+# phase function wrappers which build the package for each supported
>ABI
>+# if the flag is enabled. Otherwise, it works like regular
>+# autotools-utils.
>+#
>+# Note that the multilib support requires out-of-source builds to be
>+# enabled. Thus, it is impossible to use AUTOTOOLS_IN_SOURCE_BUILD
>with
>+# it.
>+
>+case ${EAPI:-0} in
>+	2|3|4) ;;
>+	*) die "EAPI=${EAPI} is not supported" ;;
>+esac
>+
>+if [[ ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
>+	die "${ECLASS}: multilib support requires out-of-source builds."
>+fi
>+
>+inherit autotools-utils multilib
>+
>+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
>+
>+IUSE=multilib
>+
>+# @FUNCTION: autotools-multilib_foreach_abi
>+# @USAGE: argv...
>+# @DESCRIPTION:
>+# If multilib support is enabled, sets the toolchain up for each
>+# supported ABI along with the ABI variable and correct
>+# AUTOTOOLS_BUILD_DIR, and runs the given commands with them.
>+#
>+# If multilib support is disabled, it just runs the commands. No setup
>+# is done.
>+autotools-multilib_foreach_abi() {
>+	if use multilib; then
>+		local ABI
>+		for ABI in $(get_all_abis); do
>+			multilib_toolchain_setup "${ABI}"
>+			AUTOTOOLS_BUILD_DIR=${S%%/}-${ABI} "${@}"
>+		done
>+	else
>+		"${@}"
>+	fi
>+}
>+
>+autotools-multilib_src_configure() {
>+	autotools-multilib_foreach_abi autotools-utils_src_configure
>+}
>+
>+autotools-multilib_src_compile() {
>+	autotools-multilib_foreach_abi autotools-utils_src_compile
>+}
>+
>+autotools-multilib_src_test() {
>+	autotools-multilib_foreach_abi autotools-utils_src_test
>+}
>+
>+autotools-multilib_src_install() {
>+	autotools-multilib_foreach_abi autotools-utils_src_install
>+}

How docs and nonbinaries get managed?

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sat, 22 Sep 2012 23:44:43 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> "Michał Górny" <mgorny@gentoo.org> wrote:
> 
> >It is a simple eclass using autotools out-of-source builds to build
> >packages for multiple ABIs when multilib is supported.
> >
> >Use case: xorg packages, ask Matt.
> >---
> >gx86/eclass/autotools-multilib.eclass | 72
> >+++++++++++++++++++++++++++++++++++
> > 1 file changed, 72 insertions(+)
> > create mode 100644 gx86/eclass/autotools-multilib.eclass
> >
> >diff --git a/gx86/eclass/autotools-multilib.eclass
> >b/gx86/eclass/autotools-multilib.eclass
> >new file mode 100644
> >index 0000000..1a345a1
> >--- /dev/null
> >+++ b/gx86/eclass/autotools-multilib.eclass
> >@@ -0,0 +1,72 @@
> >+# Copyright 1999-2012 Gentoo Foundation
> >+# Distributed under the terms of the GNU General Public License v2
> >+# $Header: $
> >+
> >+# @ECLASS: autotools-multilib.eclass
> >+# @MAINTAINER:
> >+# Michał Górny <mgorny@gentoo.org>
> >+# @BLURB: autotools-utils wrapper for multilib builds
> >+# @DESCRIPTION:
> >+# The autotools-multilib.eclass is an autotools-utils.eclass(5)
> >wrapper
> >+# introducing support for building for more than one ABI (multilib).
> >+#
> >+# Inheriting this eclass sets IUSE=multilib and exports
> >autotools-utils
> >+# phase function wrappers which build the package for each supported
> >ABI
> >+# if the flag is enabled. Otherwise, it works like regular
> >+# autotools-utils.
> >+#
> >+# Note that the multilib support requires out-of-source builds to be
> >+# enabled. Thus, it is impossible to use AUTOTOOLS_IN_SOURCE_BUILD
> >with
> >+# it.
> >+
> >+case ${EAPI:-0} in
> >+	2|3|4) ;;
> >+	*) die "EAPI=${EAPI} is not supported" ;;
> >+esac
> >+
> >+if [[ ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
> >+	die "${ECLASS}: multilib support requires out-of-source
> >builds." +fi
> >+
> >+inherit autotools-utils multilib
> >+
> >+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
> >+
> >+IUSE=multilib
> >+
> >+# @FUNCTION: autotools-multilib_foreach_abi
> >+# @USAGE: argv...
> >+# @DESCRIPTION:
> >+# If multilib support is enabled, sets the toolchain up for each
> >+# supported ABI along with the ABI variable and correct
> >+# AUTOTOOLS_BUILD_DIR, and runs the given commands with them.
> >+#
> >+# If multilib support is disabled, it just runs the commands. No
> >setup +# is done.
> >+autotools-multilib_foreach_abi() {
> >+	if use multilib; then
> >+		local ABI
> >+		for ABI in $(get_all_abis); do
> >+			multilib_toolchain_setup "${ABI}"
> >+			AUTOTOOLS_BUILD_DIR=${S%%/}-${ABI} "${@}"
> >+		done
> >+	else
> >+		"${@}"
> >+	fi
> >+}
> >+
> >+autotools-multilib_src_configure() {
> >+	autotools-multilib_foreach_abi autotools-utils_src_configure
> >+}
> >+
> >+autotools-multilib_src_compile() {
> >+	autotools-multilib_foreach_abi autotools-utils_src_compile
> >+}
> >+
> >+autotools-multilib_src_test() {
> >+	autotools-multilib_foreach_abi autotools-utils_src_test
> >+}
> >+
> >+autotools-multilib_src_install() {
> >+	autotools-multilib_foreach_abi autotools-utils_src_install
> >+}
> 
> How docs and nonbinaries get managed?

As usual. Installed twice, second time replacing the first ones.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Sat, 22 Sep 2012 23:24:46 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.
>

to some extent, can't you do the same by unpacking twice to different
$S and calling src_prepare/compile/install instead of their
autotools-utils counterpart with tweaked $S so that it works with almost
every ebuild ?

-- this really starts to resemble multilib portage :)

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sat, 22 Sep 2012 21:46:02 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sat, 22 Sep 2012 23:24:46 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > It is a simple eclass using autotools out-of-source builds to build
> > packages for multiple ABIs when multilib is supported.
> >
> 
> to some extent, can't you do the same by unpacking twice to different
> $S and calling src_prepare/compile/install instead of their
> autotools-utils counterpart with tweaked $S so that it works with
> almost every ebuild ?

That would make this solution inefficient. The good solutions should
not be made ugly to support corner cases.

> -- this really starts to resemble multilib portage :)

I've said already that multilib is a thing which could be done by
eclasses and doesn't need making PM scary. And Tommy says that
multilib-portage handles packages having IUSE=multilib fine.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Sun, 23 Sep 2012 09:21:20 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sat, 22 Sep 2012 21:46:02 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Sat, 22 Sep 2012 23:24:46 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > It is a simple eclass using autotools out-of-source builds to
> > > build packages for multiple ABIs when multilib is supported.
> > >
> > 
> > to some extent, can't you do the same by unpacking twice to
> > different $S and calling src_prepare/compile/install instead of
> > their autotools-utils counterpart with tweaked $S so that it works
> > with almost every ebuild ?
> 
> That would make this solution inefficient.

Why ?

> The good solutions should
> not be made ugly to support corner cases.

You are tying support to one specific build system, and one specific
usage within ebuilds. That is what I would call a corner case :)
Ebuilds already define a standardized way of building packages, why not
use this directly ?
I'm not saying your proposal is useless, it is indeed more efficient
than a generic one, but rather that a generic solution is neither much
more complicated nor that inefficient in comparison.


> > -- this really starts to resemble multilib portage :)
> 
> I've said already that multilib is a thing which could be done by
> eclasses and doesn't need making PM scary. And Tommy says that
> multilib-portage handles packages having IUSE=multilib fine.

I agree with that, it also has two main advantages over multilib
portage: it can be used right now and ensures that packages have their
multilib builds tested before exposing it to users.

A.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sun, 23 Sep 2012 12:47:44 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 23 Sep 2012 09:21:20 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Sat, 22 Sep 2012 21:46:02 -0300
> > Alexis Ballier <aballier@gentoo.org> wrote:
> > 
> > > On Sat, 22 Sep 2012 23:24:46 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > 
> > > > It is a simple eclass using autotools out-of-source builds to
> > > > build packages for multiple ABIs when multilib is supported.
> > > >
> > > 
> > > to some extent, can't you do the same by unpacking twice to
> > > different $S and calling src_prepare/compile/install instead of
> > > their autotools-utils counterpart with tweaked $S so that it works
> > > with almost every ebuild ?
> > 
> > That would make this solution inefficient.
> 
> Why ?

Because it introduces unnecessarily copying files around.

> > The good solutions should
> > not be made ugly to support corner cases.
> 
> You are tying support to one specific build system, and one specific
> usage within ebuilds. That is what I would call a corner case :)
> Ebuilds already define a standardized way of building packages, why not
> use this directly ?
> I'm not saying your proposal is useless, it is indeed more efficient
> than a generic one, but rather that a generic solution is neither much
> more complicated nor that inefficient in comparison.

It's a common case.

A generic solution is more complicated if it is supposed to use phase
functions exported by some eclass. By using a generic solution you lose
the ability to 'automagically' use last exported function.

Some time ago I suggested replacing 'default' with something like
'next' (which would allow one exported phase function to call the one
from next inherited eclass) but I don't think I got any response.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Sun, 23 Sep 2012 18:31:25 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 23 Sep 2012 12:47:44 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Sun, 23 Sep 2012 09:21:20 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > On Sat, 22 Sep 2012 21:46:02 -0300
> > > Alexis Ballier <aballier@gentoo.org> wrote:
> > > 
> > > > On Sat, 22 Sep 2012 23:24:46 +0200
> > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > 
> > > > > It is a simple eclass using autotools out-of-source builds to
> > > > > build packages for multiple ABIs when multilib is supported.
> > > > >
> > > > 
> > > > to some extent, can't you do the same by unpacking twice to
> > > > different $S and calling src_prepare/compile/install instead of
> > > > their autotools-utils counterpart with tweaked $S so that it
> > > > works with almost every ebuild ?
> > > 
> > > That would make this solution inefficient.
> > 
> > Why ?
> 
> Because it introduces unnecessarily copying files around.

cp -l ? I can live with that.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Mon, 24 Sep 2012 12:17:58 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 23 Sep 2012 18:31:25 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Sun, 23 Sep 2012 12:47:44 -0300
> > Alexis Ballier <aballier@gentoo.org> wrote:
> > 
> > > On Sun, 23 Sep 2012 09:21:20 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > 
> > > > On Sat, 22 Sep 2012 21:46:02 -0300
> > > > Alexis Ballier <aballier@gentoo.org> wrote:
> > > > 
> > > > > On Sat, 22 Sep 2012 23:24:46 +0200
> > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > 
> > > > > > It is a simple eclass using autotools out-of-source builds to
> > > > > > build packages for multiple ABIs when multilib is supported.
> > > > > >
> > > > > 
> > > > > to some extent, can't you do the same by unpacking twice to
> > > > > different $S and calling src_prepare/compile/install instead of
> > > > > their autotools-utils counterpart with tweaked $S so that it
> > > > > works with almost every ebuild ?
> > > > 
> > > > That would make this solution inefficient.
> > > 
> > > Why ?
> > 
> > Because it introduces unnecessarily copying files around.
> 
> cp -l ? I can live with that.

Can you guarantee that the build system won't modify any file
in the source tree? And AFAIR we don't have any COW filesystems
in Gentoo.

So it's back to optimized solution vs bad, universal solution.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Mon, 24 Sep 2012 19:32:14 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 24 Sep 2012 12:17:58 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Sun, 23 Sep 2012 18:31:25 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > On Sun, 23 Sep 2012 12:47:44 -0300
> > > Alexis Ballier <aballier@gentoo.org> wrote:
> > > 
> > > > On Sun, 23 Sep 2012 09:21:20 +0200
> > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > 
> > > > > On Sat, 22 Sep 2012 21:46:02 -0300
> > > > > Alexis Ballier <aballier@gentoo.org> wrote:
> > > > > 
> > > > > > On Sat, 22 Sep 2012 23:24:46 +0200
> > > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > > 
> > > > > > > It is a simple eclass using autotools out-of-source
> > > > > > > builds to build packages for multiple ABIs when multilib
> > > > > > > is supported.
> > > > > > >
> > > > > > 
> > > > > > to some extent, can't you do the same by unpacking twice to
> > > > > > different $S and calling src_prepare/compile/install
> > > > > > instead of their autotools-utils counterpart with tweaked
> > > > > > $S so that it works with almost every ebuild ?
> > > > > 
> > > > > That would make this solution inefficient.
> > > > 
> > > > Why ?
> > > 
> > > Because it introduces unnecessarily copying files around.
> > 
> > cp -l ? I can live with that.
> 
> Can you guarantee that the build system won't modify any file
> in the source tree?

You can add it as a requirement. Your eclass implicitly requires it
anyway.

> So it's back to optimized solution vs bad, universal solution.

or rather writing multilib support for every package vs. using what
ebuilds already offer you: a common API for building every package.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Mon, 24 Sep 2012 14:53:27 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Mon, 24 Sep 2012 19:32:14 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Mon, 24 Sep 2012 12:17:58 -0300
> > Alexis Ballier <aballier@gentoo.org> wrote:
> > 
> > > On Sun, 23 Sep 2012 18:31:25 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > 
> > > > On Sun, 23 Sep 2012 12:47:44 -0300
> > > > Alexis Ballier <aballier@gentoo.org> wrote:
> > > > 
> > > > > On Sun, 23 Sep 2012 09:21:20 +0200
> > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > 
> > > > > > On Sat, 22 Sep 2012 21:46:02 -0300
> > > > > > Alexis Ballier <aballier@gentoo.org> wrote:
> > > > > > 
> > > > > > > On Sat, 22 Sep 2012 23:24:46 +0200
> > > > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > > > 
> > > > > > > > It is a simple eclass using autotools out-of-source
> > > > > > > > builds to build packages for multiple ABIs when multilib
> > > > > > > > is supported.
> > > > > > > >
> > > > > > > 
> > > > > > > to some extent, can't you do the same by unpacking twice to
> > > > > > > different $S and calling src_prepare/compile/install
> > > > > > > instead of their autotools-utils counterpart with tweaked
> > > > > > > $S so that it works with almost every ebuild ?
> > > > > > 
> > > > > > That would make this solution inefficient.
> > > > > 
> > > > > Why ?
> > > > 
> > > > Because it introduces unnecessarily copying files around.
> > > 
> > > cp -l ? I can live with that.
> > 
> > Can you guarantee that the build system won't modify any file
> > in the source tree?
> 
> You can add it as a requirement. Your eclass implicitly requires it
> anyway.
> 
> > So it's back to optimized solution vs bad, universal solution.
> 
> or rather writing multilib support for every package vs. using what
> ebuilds already offer you: a common API for building every package.

Ebuilds don't offer me anything if I have to rewrite phase functions
anyway...

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Mon, 24 Sep 2012 20:12:40 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> > > > > > > > to some extent, can't you do the same by unpacking
> > > > > > > > twice to different $S and calling
> > > > > > > > src_prepare/compile/install instead of their
> > > > > > > > autotools-utils counterpart with tweaked $S so that it
> > > > > > > > works with almost every ebuild ?

[...]

> Ebuilds don't offer me anything if I have to rewrite phase functions
> anyway...

what, in the above quote, makes you think you need to rewrite anything ?

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Mon, 24 Sep 2012 16:16:53 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Mon, 24 Sep 2012 20:12:40 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > > > > > > > > to some extent, can't you do the same by unpacking
> > > > > > > > > twice to different $S and calling
> > > > > > > > > src_prepare/compile/install instead of their
> > > > > > > > > autotools-utils counterpart with tweaked $S so that it
> > > > > > > > > works with almost every ebuild ?
> 
> [...]
> 
> > Ebuilds don't offer me anything if I have to rewrite phase functions
> > anyway...
> 
> what, in the above quote, makes you think you need to rewrite anything ?

1. If ebuild has phase functions, they override the eclass.
2. If eclass exports phase functions, they have no way of calling
'previous' eclass phase functions.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Mon, 24 Sep 2012 22:47:33 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 24 Sep 2012 16:16:53 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Mon, 24 Sep 2012 20:12:40 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > > > > > > > > to some extent, can't you do the same by unpacking
> > > > > > > > > > twice to different $S and calling
> > > > > > > > > > src_prepare/compile/install instead of their
> > > > > > > > > > autotools-utils counterpart with tweaked $S so that
> > > > > > > > > > it works with almost every ebuild ?
> > 
> > [...]
> > 
> > > Ebuilds don't offer me anything if I have to rewrite phase
> > > functions anyway...
> > 
> > what, in the above quote, makes you think you need to rewrite
> > anything ?
> 
> 1. If ebuild has phase functions, they override the eclass.
> 2. If eclass exports phase functions, they have no way of calling
> 'previous' eclass phase functions.
> 

you dont need this, the PM has already done the work for you: call
directly the relevant function.

src_multilib_compile() {
	forall ABIS; do
		prepare ABI variables
		src_compile
	done
}

then, in a future EAPI, let the PM call src_multilib_compile instead
of src_compile if multilib is requested.

this needs very minimal PM/EAPI support, leaves the multilib code
into eclasses, leaves multilib opt-in so that noarch or packages not
installing a lib dont need to care, and also leaves room for cleaner
more specific eclasses like yours

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> you dont need this, the PM has already done the work for you: call
> directly the relevant function.
> 
> src_multilib_compile() {
> 	forall ABIS; do
> 		prepare ABI variables
> 		src_compile
> 	done
> }

Err, what? Who calls the function? Where?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 24 Sep 2012 18:19:43 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > you dont need this, the PM has already done the work for you: call
> > directly the relevant function.
> > 
> > src_multilib_compile() {
> > 	forall ABIS; do
> > 		prepare ABI variables
> > 		src_compile
> > 	done
> > }
> 
> Err, what? Who calls the function? Where?

bash. here.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Mon, 24 Sep 2012 18:59:14 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Mon, 24 Sep 2012 23:51:27 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Mon, 24 Sep 2012 18:19:43 -0300
> > Alexis Ballier <aballier@gentoo.org> wrote:
> > 
> > > you dont need this, the PM has already done the work for you: call
> > > directly the relevant function.
> > > 
> > > src_multilib_compile() {
> > > 	forall ABIS; do
> > > 		prepare ABI variables
> > > 		src_compile
> > > 	done
> > > }
> > 
> > Err, what? Who calls the function? Where?
> 
> bash. here.

How can an eclass call a phase function while eclass needs to be called
from the phase function to call the phase function...?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Tue, 25 Sep 2012 00:10:21 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 24 Sep 2012 18:59:14 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Mon, 24 Sep 2012 23:51:27 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > On Mon, 24 Sep 2012 18:19:43 -0300
> > > Alexis Ballier <aballier@gentoo.org> wrote:
> > > 
> > > > you dont need this, the PM has already done the work for you:
> > > > call directly the relevant function.
> > > > 
> > > > src_multilib_compile() {
> > > > 	forall ABIS; do
> > > > 		prepare ABI variables
> > > > 		src_compile
> > > > 	done
> > > > }
> > > 
> > > Err, what? Who calls the function? Where?
> > 
> > bash. here.
> 
> How can an eclass call a phase function while eclass needs to be
> called from the phase function to call the phase function...?
> 

Read again. Esp. the part you deleted.
I never said it should do this, on purpose...

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Mon, Sep 24, 2012 at 3:22 PM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Tue, 25 Sep 2012 00:10:21 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
>> On Mon, 24 Sep 2012 18:59:14 -0300
>> Alexis Ballier <aballier@gentoo.org> wrote:
>>
>> > On Mon, 24 Sep 2012 23:51:27 +0200
>> > Michał Górny <mgorny@gentoo.org> wrote:
>> >
>> > > On Mon, 24 Sep 2012 18:19:43 -0300
>> > > Alexis Ballier <aballier@gentoo.org> wrote:
>> > >
>> > > > you dont need this, the PM has already done the work for you:
>> > > > call directly the relevant function.
>> > > >
>> > > > src_multilib_compile() {
>> > > >         forall ABIS; do
>> > > >                 prepare ABI variables
>> > > >                 src_compile
>> > > >         done
>> > > > }
>> > >
>> > > Err, what? Who calls the function? Where?
>> >
>> > bash. here.
>>
>> How can an eclass call a phase function while eclass needs to be
>> called from the phase function to call the phase function...?
>>
>
> Read again. Esp. the part you deleted.
> I never said it should do this, on purpose...
>

I'm especially confused by what your point is. I can't see how your
snippet could ever work, and you're being evasive about answering
that.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Mon, 24 Sep 2012 17:44:33 -0700
Matt Turner <mattst88@gentoo.org> wrote:

> On Mon, Sep 24, 2012 at 3:22 PM, Alexis Ballier <aballier@gentoo.org>
> wrote:
> > On Tue, 25 Sep 2012 00:10:21 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> >> On Mon, 24 Sep 2012 18:59:14 -0300
> >> Alexis Ballier <aballier@gentoo.org> wrote:
> >>
> >> > On Mon, 24 Sep 2012 23:51:27 +0200
> >> > Michał Górny <mgorny@gentoo.org> wrote:
> >> >
> >> > > On Mon, 24 Sep 2012 18:19:43 -0300
> >> > > Alexis Ballier <aballier@gentoo.org> wrote:
> >> > >
> >> > > > you dont need this, the PM has already done the work for you:
> >> > > > call directly the relevant function.
> >> > > >
> >> > > > src_multilib_compile() {
> >> > > >         forall ABIS; do
> >> > > >                 prepare ABI variables
> >> > > >                 src_compile
> >> > > >         done
> >> > > > }
> >> > >
> >> > > Err, what? Who calls the function? Where?
> >> >
> >> > bash. here.
> >>
> >> How can an eclass call a phase function while eclass needs to be
> >> called from the phase function to call the phase function...?
> >>
> >
> > Read again. Esp. the part you deleted.
> > I never said it should do this, on purpose...
> >
> 
> I'm especially confused by what your point is. I can't see how your
> snippet could ever work, and you're being evasive about answering
> that.
> 

both of you are putting words in my mouth then: obviously, if you call
your eclass multilib and the above function multilib_src_compile and
then pass it through EXPORT_FUNCTIONS, then it will loop.

let me copy paste what i wrote for you:

"""
then, in a future EAPI, let the PM call src_multilib_compile instead
of src_compile if multilib is requested.
"""

nothing more...

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.

Thanks a lot, Michał! This looks good to me.

> Use case: xorg packages, ask Matt.

So the idea is that users want up-to-date 32-bit drivers for games and
WINE. The emul- packages aren't a very good solution for a number of
reasons.

I'd like to add multilib USE flags to Mesa and thus its dependencies.
I realized that almost everything in x11-libs/ could be converted very
easily, which would allow us to get rid of emul-linux-x86-xlibs in
addition to emul-linux-x86-opengl.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Diego Elio Pettenò]

On 22/09/2012 18:54, Matt Turner wrote:
> I'd like to add multilib USE flags to Mesa and thus its dependencies.
> I realized that almost everything in x11-libs/ could be converted very
> easily, which would allow us to get rid of emul-linux-x86-xlibs in
> addition to emul-linux-x86-opengl.

If that's the case, please consider a more broad strategy, in particular:

 - unforce the multilib flag for the packages that are _built_ for multilib;
 - make 32-bit binary packages depend amd64? ( whatever[multilib] )
instead of blanketing all xlibs.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sat, Sep 22, 2012 at 6:59 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> On 22/09/2012 18:54, Matt Turner wrote:
>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
>> I realized that almost everything in x11-libs/ could be converted very
>> easily, which would allow us to get rid of emul-linux-x86-xlibs in
>> addition to emul-linux-x86-opengl.
>
> If that's the case, please consider a more broad strategy, in particular:
>
>  - unforce the multilib flag for the packages that are _built_ for multilib;

In progress: https://bugs.gentoo.org/show_bug.cgi?id=435094 :)

>  - make 32-bit binary packages depend amd64? ( whatever[multilib] )
> instead of blanketing all xlibs.

I think this means "make 32-bit binary packages' dependencies on amd64
not use the emul- packages"? If so, that'd certainly be a component of
getting rid of emul-linux-x86-xlibs. It's not in the scope of my
project to get rid of /all/ of the emul- packages, but I agree that
that is a worthwhile goal.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Diego Elio Pettenò]

On 22/09/2012 20:42, Matt Turner wrote:
> I think this means "make 32-bit binary packages' dependencies on amd64
> not use the emul- packages"? If so, that'd certainly be a component of
> getting rid of emul-linux-x86-xlibs. It's not in the scope of my
> project to get rid of /all/ of the emul- packages, but I agree that
> that is a worthwhile goal.

Mostly I don't want to have to build Xaw in both variants given I use
neither.. but that would happen if you just made the emul depend on the
packages that are converted...

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sun, Sep 23, 2012 at 9:07 AM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> On 22/09/2012 20:42, Matt Turner wrote:
>> I think this means "make 32-bit binary packages' dependencies on amd64
>> not use the emul- packages"? If so, that'd certainly be a component of
>> getting rid of emul-linux-x86-xlibs. It's not in the scope of my
>> project to get rid of /all/ of the emul- packages, but I agree that
>> that is a worthwhile goal.
>
> Mostly I don't want to have to build Xaw in both variants given I use
> neither.. but that would happen if you just made the emul depend on the
> packages that are converted...

Ahh, indeed. You mean that existing dependencies on
emul-linux-x86-xlibs should be converted into finer-grained
dependencies on individual libraries. Of course, that is a very good
idea.

In the case of Xaw, I added a deprecated USE flag recently that
controls the building of the old Xaw6, so we're already working toward
trimming Xaw from users' systems. :)

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Thomas Sachau]

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

Matt Turner schrieb:
> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> It is a simple eclass using autotools out-of-source builds to build
>> packages for multiple ABIs when multilib is supported.
> 
> Thanks a lot, Michał! This looks good to me.
> 
>> Use case: xorg packages, ask Matt.
> 
> So the idea is that users want up-to-date 32-bit drivers for games and
> WINE. The emul- packages aren't a very good solution for a number of
> reasons.
> 
> I'd like to add multilib USE flags to Mesa and thus its dependencies.
> I realized that almost everything in x11-libs/ could be converted very
> easily, which would allow us to get rid of emul-linux-x86-xlibs in
> addition to emul-linux-x86-opengl.
> 
> 

This looks like a shortened duplication of a subset of multilib-portage
features. While this wont hurt multilib-portage (since it does exclude
most actions on ebuilds with USE=multilib), it will mean a rewrite for
many ebuilds, which then again need another rewrite (or more likely
revert), when multilib-portage is accepted in a future EAPI.

So i would prefer some help/support with multilib-portage to get it
accepted sooner, instead of this additional workaround for a subset of
packages.

P.S.: I know, that users, who want up-to-date 32bit drivers for games
and wine do use multilib-portage, so we already have a working solution
for this issue.

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sun, 23 Sep 2012 11:07:30 +0200
Thomas Sachau <tommy@gentoo.org> wrote:

> Matt Turner schrieb:
> > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> >> It is a simple eclass using autotools out-of-source builds to build
> >> packages for multiple ABIs when multilib is supported.
> > 
> > Thanks a lot, Michał! This looks good to me.
> > 
> >> Use case: xorg packages, ask Matt.
> > 
> > So the idea is that users want up-to-date 32-bit drivers for games and
> > WINE. The emul- packages aren't a very good solution for a number of
> > reasons.
> > 
> > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > I realized that almost everything in x11-libs/ could be converted very
> > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > addition to emul-linux-x86-opengl.
> > 
> > 
> 
> This looks like a shortened duplication of a subset of multilib-portage
> features. While this wont hurt multilib-portage (since it does exclude
> most actions on ebuilds with USE=multilib), it will mean a rewrite for
> many ebuilds, which then again need another rewrite (or more likely
> revert), when multilib-portage is accepted in a future EAPI.

s/when/if/

> So i would prefer some help/support with multilib-portage to get it
> accepted sooner, instead of this additional workaround for a subset of
> packages.

I prefer the simpler solution.

> P.S.: I know, that users, who want up-to-date 32bit drivers for games
> and wine do use multilib-portage, so we already have a working solution
> for this issue.

They will no longer have to do that.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/23/2012 11:56 AM, Michał Górny wrote:
>> So i would prefer some help/support with multilib-portage to get
>> it accepted sooner, instead of this additional workaround for a
>> subset of packages.
> 
> I prefer the simpler solution.
> 

I prefer the stronger solution. This is just a quick workaround.

- -1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQXt4ZAAoJEFpvPKfnPDWzuaUH/0EfL7BxiHQo+E1KvUHNrqlX
YD1bt5c/TU82XMAQ4axqYDXSYHE8o/WYJPNFJy2ZZhseFlG1lOo9DxOd+zVIf7JE
JqbIWbgJ6r+POKWREDTH8ZWQaq3r1G4BeOH7IbxwuGrLmTUp36oSpVRYX5XnXyl0
3MvRe9bXpih8exwOJudncc/4NFtX9c12wO6CifH0xKwcr7lu7k6jpRyfD3dIpXXq
QQlY4MjuCfy6aHxp+4+CvL9WEZ4cmkXxoi/EZCsMZYb+jBQ1NF0Jxr6tULX575vz
Vvm+n3sdTPMkh863vrAmglwFYtDgucmp/OeYZD03g3Ef52x1/NefkIGcwXGUjlY=
=FXgk
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sun, 23 Sep 2012 12:02:01 +0200
hasufell <hasufell@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/23/2012 11:56 AM, Michał Górny wrote:
> >> So i would prefer some help/support with multilib-portage to get
> >> it accepted sooner, instead of this additional workaround for a
> >> subset of packages.
> > 
> > I prefer the simpler solution.
> > 
> 
> I prefer the stronger solution. This is just a quick workaround.

How is it stronger? By doing implicit magic on every ebuild?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/23/2012 12:40 PM, Michał Górny wrote:
> On Sun, 23 Sep 2012 12:02:01 +0200 hasufell <hasufell@gentoo.org>
> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 09/23/2012 11:56 AM, Michał Górny wrote:
>>>> So i would prefer some help/support with multilib-portage to
>>>> get it accepted sooner, instead of this additional workaround
>>>> for a subset of packages.
>>> 
>>> I prefer the simpler solution.
>>> 
>> 
>> I prefer the stronger solution. This is just a quick workaround.
> 
> How is it stronger? By doing implicit magic on every ebuild?
> 

a) does not involve modifying ebuilds
b) works in a larger scale
c) is tested and developed for quite some time
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQXvsmAAoJEFpvPKfnPDWzZAcH/11b4Wng7f+nyDpbFQhanpLW
56mQy4IGmEvmEqgrYyBPLtnXWh+BtNu+j0ogS8hNMxsVXvDw6HvJGbeXwebcQ6VY
OQS5l0IZvK9Zz+H4wm+ACv1i6fWPG9nRuMg8phRwfnq0jMIIF2lP1nll5T/2QYU/
fvPxiweKca9id4hozc0C0319vpVjEoX9a8/dBh6JXGNlzPq54bf7+6qep8O7mWGo
9bKXkoobwd22wUnBajcOFg4mbMu7cnKsTn0PhQBXo2+tEV5MhgugGe8USq99u8xA
CQVVRcdbjyQZW90W8c0/Dniq8LMcTY6xoKmH5a2vG0dpHahYtKtCZ2sTruxgppc=
=KNcl
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sun, 23 Sep 2012 14:05:58 +0200
hasufell <hasufell@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/23/2012 12:40 PM, Michał Górny wrote:
> > On Sun, 23 Sep 2012 12:02:01 +0200 hasufell <hasufell@gentoo.org>
> > wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> On 09/23/2012 11:56 AM, Michał Górny wrote:
> >>>> So i would prefer some help/support with multilib-portage to
> >>>> get it accepted sooner, instead of this additional workaround
> >>>> for a subset of packages.
> >>> 
> >>> I prefer the simpler solution.
> >>> 
> >> 
> >> I prefer the stronger solution. This is just a quick workaround.
> > 
> > How is it stronger? By doing implicit magic on every ebuild?
> > 
> 
> a) does not involve modifying ebuilds

How can you tell whether a particular ebuild does install libraries
which are suitable for multilib? Or are we enforcing multilib for every
single program now?

> c) is tested and developed for quite some time

Building packages on two ABIs was developed quite a long time ago,
and was tested since.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sun, Sep 23, 2012 at 3:02 AM, hasufell <hasufell@gentoo.org> wrote:
> I prefer the stronger solution. This is just a quick workaround.

And I'd prefer if people who aren't involved with what I'm working on
don't try to block my progress.

I appreciate your opinion, and truthfully I'd just rather have portage
handle this for me but until that time comes I'm going to use Michal's
eclass.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Zac Medico]

On 09/23/2012 03:02 AM, hasufell wrote:
> On 09/23/2012 11:56 AM, Michał Górny wrote:
>>> So i would prefer some help/support with multilib-portage to get
>>> it accepted sooner, instead of this additional workaround for a
>>> subset of packages.
> 
>> I prefer the simpler solution.
> 
> 
> I prefer the stronger solution. This is just a quick workaround.
> 
> -1
> 

I'm in favor of adding multilib functions to the package manager in a
future EAPI, but I'm not convinced that the current multilib-portage
branch is using the best design. For example, it recently came to my
attention that it calls pkg_preinst in a loop for each multilib-ABI.
This seems like a bad idea to me, since pkg_preinst often contains stuff
that only needs to run once, rather than for each multilib-ABI. I would
prefer that such loops be coded explicitly in pkg_preinst whenever they
are needed, and approach taken by the proposed autotools-multilib.eclass
is more in alignment with this preference.
-- 
Thanks,
Zac

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

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

El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 11:07:30 +0200
> Thomas Sachau <tommy@gentoo.org> wrote:
> 
> > Matt Turner schrieb:
> > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > >> It is a simple eclass using autotools out-of-source builds to build
> > >> packages for multiple ABIs when multilib is supported.
> > > 
> > > Thanks a lot, Michał! This looks good to me.
> > > 
> > >> Use case: xorg packages, ask Matt.
> > > 
> > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > WINE. The emul- packages aren't a very good solution for a number of
> > > reasons.
> > > 
> > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > I realized that almost everything in x11-libs/ could be converted very
> > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > addition to emul-linux-x86-opengl.
> > > 
> > > 
> > 
> > This looks like a shortened duplication of a subset of multilib-portage
> > features. While this wont hurt multilib-portage (since it does exclude
> > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > many ebuilds, which then again need another rewrite (or more likely
> > revert), when multilib-portage is accepted in a future EAPI.
> 
> s/when/if/
> 
> > So i would prefer some help/support with multilib-portage to get it
> > accepted sooner, instead of this additional workaround for a subset of
> > packages.
> 
> I prefer the simpler solution.
> 
> > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > and wine do use multilib-portage, so we already have a working solution
> > for this issue.
> 
> They will no longer have to do that.
> 

I would prefer if eclass way could be extended to packages not using
autotools too, otherwise, we will still need emul packages for, for
example, qt libs. If that would be possible via eclass, maybe
multilib-portage wouldn't be needed but, if not, we will still need it
and, then, would be nice if this inclussion for autotools packages
wouldn't cause more problems to get the "strong" solution land in the
"near" future :/

The simpler solution (eclass) looks fine to me, but it would need to be
extended to more packages than autotools based ones to let it replace
portage-multilib/emul packages

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sun, 23 Sep 2012 12:33:58 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > On Sun, 23 Sep 2012 11:07:30 +0200
> > Thomas Sachau <tommy@gentoo.org> wrote:
> > 
> > > Matt Turner schrieb:
> > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > >> It is a simple eclass using autotools out-of-source builds to build
> > > >> packages for multiple ABIs when multilib is supported.
> > > > 
> > > > Thanks a lot, Michał! This looks good to me.
> > > > 
> > > >> Use case: xorg packages, ask Matt.
> > > > 
> > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > reasons.
> > > > 
> > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > I realized that almost everything in x11-libs/ could be converted very
> > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > addition to emul-linux-x86-opengl.
> > > > 
> > > > 
> > > 
> > > This looks like a shortened duplication of a subset of multilib-portage
> > > features. While this wont hurt multilib-portage (since it does exclude
> > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > many ebuilds, which then again need another rewrite (or more likely
> > > revert), when multilib-portage is accepted in a future EAPI.
> > 
> > s/when/if/
> > 
> > > So i would prefer some help/support with multilib-portage to get it
> > > accepted sooner, instead of this additional workaround for a subset of
> > > packages.
> > 
> > I prefer the simpler solution.
> > 
> > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > and wine do use multilib-portage, so we already have a working solution
> > > for this issue.
> > 
> > They will no longer have to do that.
> > 
> 
> I would prefer if eclass way could be extended to packages not using
> autotools too, otherwise, we will still need emul packages for, for
> example, qt libs. If that would be possible via eclass, maybe
> multilib-portage wouldn't be needed but, if not, we will still need it
> and, then, would be nice if this inclussion for autotools packages
> wouldn't cause more problems to get the "strong" solution land in the
> "near" future :/
> 
> The simpler solution (eclass) looks fine to me, but it would need to be
> extended to more packages than autotools based ones to let it replace
> portage-multilib/emul packages

Qt uses cmake, doesn't it?

I don't mind having cmake-multilib as well? We could probably move
the foreach_abi() function to some more common eclass, like multilib
eclass.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

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

El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 12:33:58 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > > On Sun, 23 Sep 2012 11:07:30 +0200
> > > Thomas Sachau <tommy@gentoo.org> wrote:
> > > 
> > > > Matt Turner schrieb:
> > > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > > >> It is a simple eclass using autotools out-of-source builds to build
> > > > >> packages for multiple ABIs when multilib is supported.
> > > > > 
> > > > > Thanks a lot, Michał! This looks good to me.
> > > > > 
> > > > >> Use case: xorg packages, ask Matt.
> > > > > 
> > > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > > reasons.
> > > > > 
> > > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > > I realized that almost everything in x11-libs/ could be converted very
> > > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > > addition to emul-linux-x86-opengl.
> > > > > 
> > > > > 
> > > > 
> > > > This looks like a shortened duplication of a subset of multilib-portage
> > > > features. While this wont hurt multilib-portage (since it does exclude
> > > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > > many ebuilds, which then again need another rewrite (or more likely
> > > > revert), when multilib-portage is accepted in a future EAPI.
> > > 
> > > s/when/if/
> > > 
> > > > So i would prefer some help/support with multilib-portage to get it
> > > > accepted sooner, instead of this additional workaround for a subset of
> > > > packages.
> > > 
> > > I prefer the simpler solution.
> > > 
> > > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > > and wine do use multilib-portage, so we already have a working solution
> > > > for this issue.
> > > 
> > > They will no longer have to do that.
> > > 
> > 
> > I would prefer if eclass way could be extended to packages not using
> > autotools too, otherwise, we will still need emul packages for, for
> > example, qt libs. If that would be possible via eclass, maybe
> > multilib-portage wouldn't be needed but, if not, we will still need it
> > and, then, would be nice if this inclussion for autotools packages
> > wouldn't cause more problems to get the "strong" solution land in the
> > "near" future :/
> > 
> > The simpler solution (eclass) looks fine to me, but it would need to be
> > extended to more packages than autotools based ones to let it replace
> > portage-multilib/emul packages
> 
> Qt uses cmake, doesn't it?
> 
> I don't mind having cmake-multilib as well? We could probably move
> the foreach_abi() function to some more common eclass, like multilib
> eclass.
> 

Looks interesting, yes, it uses cmake. I guess we would need to move all
packages needing 32bits libs to this eclasses. Are you sure wouldn't be
better to try to go to an "upper" level like Alexis Ballier suggested
some messages ago?:
"On Sat, 22 Sep 2012 23:24:46 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.
>

to some extent, can't you do the same by unpacking twice to different
$S and calling src_prepare/compile/install instead of their
autotools-utils counterpart with tweaked $S so that it works with almost
every ebuild ?

-- this really starts to resemble multilib portage :)"

That would be better as there are a ton of ebuilds not inheritting
autotools-utils.eclass even being autotools based (think for example in
gnome packages or many others)


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sun, 23 Sep 2012 13:03:56 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> > On Sun, 23 Sep 2012 12:33:58 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > 
> > > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > > > On Sun, 23 Sep 2012 11:07:30 +0200
> > > > Thomas Sachau <tommy@gentoo.org> wrote:
> > > > 
> > > > > Matt Turner schrieb:
> > > > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > > > >> It is a simple eclass using autotools out-of-source builds to build
> > > > > >> packages for multiple ABIs when multilib is supported.
> > > > > > 
> > > > > > Thanks a lot, Michał! This looks good to me.
> > > > > > 
> > > > > >> Use case: xorg packages, ask Matt.
> > > > > > 
> > > > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > > > reasons.
> > > > > > 
> > > > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > > > I realized that almost everything in x11-libs/ could be converted very
> > > > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > > > addition to emul-linux-x86-opengl.
> > > > > > 
> > > > > > 
> > > > > 
> > > > > This looks like a shortened duplication of a subset of multilib-portage
> > > > > features. While this wont hurt multilib-portage (since it does exclude
> > > > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > > > many ebuilds, which then again need another rewrite (or more likely
> > > > > revert), when multilib-portage is accepted in a future EAPI.
> > > > 
> > > > s/when/if/
> > > > 
> > > > > So i would prefer some help/support with multilib-portage to get it
> > > > > accepted sooner, instead of this additional workaround for a subset of
> > > > > packages.
> > > > 
> > > > I prefer the simpler solution.
> > > > 
> > > > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > > > and wine do use multilib-portage, so we already have a working solution
> > > > > for this issue.
> > > > 
> > > > They will no longer have to do that.
> > > > 
> > > 
> > > I would prefer if eclass way could be extended to packages not using
> > > autotools too, otherwise, we will still need emul packages for, for
> > > example, qt libs. If that would be possible via eclass, maybe
> > > multilib-portage wouldn't be needed but, if not, we will still need it
> > > and, then, would be nice if this inclussion for autotools packages
> > > wouldn't cause more problems to get the "strong" solution land in the
> > > "near" future :/
> > > 
> > > The simpler solution (eclass) looks fine to me, but it would need to be
> > > extended to more packages than autotools based ones to let it replace
> > > portage-multilib/emul packages
> > 
> > Qt uses cmake, doesn't it?
> > 
> > I don't mind having cmake-multilib as well? We could probably move
> > the foreach_abi() function to some more common eclass, like multilib
> > eclass.
> > 
> 
> Looks interesting, yes, it uses cmake. I guess we would need to move all
> packages needing 32bits libs to this eclasses. Are you sure wouldn't be
> better to try to go to an "upper" level like Alexis Ballier suggested
> some messages ago?:
> "On Sat, 22 Sep 2012 23:24:46 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > It is a simple eclass using autotools out-of-source builds to build
> > packages for multiple ABIs when multilib is supported.
> >
> 
> to some extent, can't you do the same by unpacking twice to different
> $S and calling src_prepare/compile/install instead of their
> autotools-utils counterpart with tweaked $S so that it works with almost
> every ebuild ?
> 
> -- this really starts to resemble multilib portage :)"
> 
> That would be better as there are a ton of ebuilds not inheritting
> autotools-utils.eclass even being autotools based (think for example in
> gnome packages or many others)

You could fix those ebuilds to inherit it too ;). autotools-utils was
especially designed to use out-of-source builds for multilib
in the future.

I'm afraid the 'upper level' is technically impossible without either
going into PM itself (which means waiting for EAPI 6 at least
and getting some scary logic into it) or reinventing the phases alike
ruby-ng/python-distutils-ng. Well, the latter may be useful to some
degree; still, it would require each ebuild to redefine all phases.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

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

El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió:
> On Sun, 23 Sep 2012 13:03:56 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > El dom, 23-09-2012 a las 12:40 +0200, Michał Górny escribió:
> > > On Sun, 23 Sep 2012 12:33:58 +0200
> > > Pacho Ramos <pacho@gentoo.org> wrote:
> > > 
> > > > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> > > > > On Sun, 23 Sep 2012 11:07:30 +0200
> > > > > Thomas Sachau <tommy@gentoo.org> wrote:
> > > > > 
> > > > > > Matt Turner schrieb:
> > > > > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > > > > > >> It is a simple eclass using autotools out-of-source builds to build
> > > > > > >> packages for multiple ABIs when multilib is supported.
> > > > > > > 
> > > > > > > Thanks a lot, Michał! This looks good to me.
> > > > > > > 
> > > > > > >> Use case: xorg packages, ask Matt.
> > > > > > > 
> > > > > > > So the idea is that users want up-to-date 32-bit drivers for games and
> > > > > > > WINE. The emul- packages aren't a very good solution for a number of
> > > > > > > reasons.
> > > > > > > 
> > > > > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
> > > > > > > I realized that almost everything in x11-libs/ could be converted very
> > > > > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
> > > > > > > addition to emul-linux-x86-opengl.
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > This looks like a shortened duplication of a subset of multilib-portage
> > > > > > features. While this wont hurt multilib-portage (since it does exclude
> > > > > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
> > > > > > many ebuilds, which then again need another rewrite (or more likely
> > > > > > revert), when multilib-portage is accepted in a future EAPI.
> > > > > 
> > > > > s/when/if/
> > > > > 
> > > > > > So i would prefer some help/support with multilib-portage to get it
> > > > > > accepted sooner, instead of this additional workaround for a subset of
> > > > > > packages.
> > > > > 
> > > > > I prefer the simpler solution.
> > > > > 
> > > > > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
> > > > > > and wine do use multilib-portage, so we already have a working solution
> > > > > > for this issue.
> > > > > 
> > > > > They will no longer have to do that.
> > > > > 
> > > > 
> > > > I would prefer if eclass way could be extended to packages not using
> > > > autotools too, otherwise, we will still need emul packages for, for
> > > > example, qt libs. If that would be possible via eclass, maybe
> > > > multilib-portage wouldn't be needed but, if not, we will still need it
> > > > and, then, would be nice if this inclussion for autotools packages
> > > > wouldn't cause more problems to get the "strong" solution land in the
> > > > "near" future :/
> > > > 
> > > > The simpler solution (eclass) looks fine to me, but it would need to be
> > > > extended to more packages than autotools based ones to let it replace
> > > > portage-multilib/emul packages
> > > 
> > > Qt uses cmake, doesn't it?
> > > 
> > > I don't mind having cmake-multilib as well? We could probably move
> > > the foreach_abi() function to some more common eclass, like multilib
> > > eclass.
> > > 
> > 
> > Looks interesting, yes, it uses cmake. I guess we would need to move all
> > packages needing 32bits libs to this eclasses. Are you sure wouldn't be
> > better to try to go to an "upper" level like Alexis Ballier suggested
> > some messages ago?:
> > "On Sat, 22 Sep 2012 23:24:46 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > It is a simple eclass using autotools out-of-source builds to build
> > > packages for multiple ABIs when multilib is supported.
> > >
> > 
> > to some extent, can't you do the same by unpacking twice to different
> > $S and calling src_prepare/compile/install instead of their
> > autotools-utils counterpart with tweaked $S so that it works with almost
> > every ebuild ?
> > 
> > -- this really starts to resemble multilib portage :)"
> > 
> > That would be better as there are a ton of ebuilds not inheritting
> > autotools-utils.eclass even being autotools based (think for example in
> > gnome packages or many others)
> 
> You could fix those ebuilds to inherit it too ;). autotools-utils was
> especially designed to use out-of-source builds for multilib
> in the future.
> 
> I'm afraid the 'upper level' is technically impossible without either
> going into PM itself (which means waiting for EAPI 6 at least
> and getting some scary logic into it) or reinventing the phases alike
> ruby-ng/python-distutils-ng. Well, the latter may be useful to some
> degree; still, it would require each ebuild to redefine all phases.
> 

Then, I think that main blocker to use autotools-utils.eclass more
widely is that it needs at least eapi2, then, I am unsure if all
packages currently shipped in emul packages could bump their eapi due
compat with old systems.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sun, 23 Sep 2012 13:30:41 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 23-09-2012 a las 13:13 +0200, Michał Górny escribió:
> > On Sun, 23 Sep 2012 13:03:56 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > 
> > > That would be better as there are a ton of ebuilds not inheritting
> > > autotools-utils.eclass even being autotools based (think for example in
> > > gnome packages or many others)
> > 
> > You could fix those ebuilds to inherit it too ;). autotools-utils was
> > especially designed to use out-of-source builds for multilib
> > in the future.
> > 
> > I'm afraid the 'upper level' is technically impossible without either
> > going into PM itself (which means waiting for EAPI 6 at least
> > and getting some scary logic into it) or reinventing the phases alike
> > ruby-ng/python-distutils-ng. Well, the latter may be useful to some
> > degree; still, it would require each ebuild to redefine all phases.
> > 
> 
> Then, I think that main blocker to use autotools-utils.eclass more
> widely is that it needs at least eapi2, then, I am unsure if all
> packages currently shipped in emul packages could bump their eapi due
> compat with old systems.

I doubt that is an important problem anymore, considering that portage
requires at least EAPI 2 (and some ebuilds use EAPI 3 already).

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Peter Stuge]

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

Michał, Pacho, and everyone else who suck epically at this:

CAN YOU FFS START TO TRIM QUOTES IN YOUR EMAILS!


Thank you

//Peter

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Sun, 23 Sep 2012 16:26:55 +0200
Peter Stuge <peter@stuge.se> wrote:

> Michał, Pacho, and everyone else who suck epically at this:
> 
> CAN YOU FFS START TO TRIM QUOTES IN YOUR EMAILS!

I've trimmed them in the next e-mail to the one you replied to :P.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Ben de Groot]

On 23 September 2012 18:40, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 23 Sep 2012 12:33:58 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
>
>> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
>> > On Sun, 23 Sep 2012 11:07:30 +0200
>> > Thomas Sachau <tommy@gentoo.org> wrote:
>> >
>> > > Matt Turner schrieb:
>> > > > On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> > > >> It is a simple eclass using autotools out-of-source builds to build
>> > > >> packages for multiple ABIs when multilib is supported.
>> > > >
>> > > > Thanks a lot, Michał! This looks good to me.
>> > > >
>> > > >> Use case: xorg packages, ask Matt.
>> > > >
>> > > > So the idea is that users want up-to-date 32-bit drivers for games and
>> > > > WINE. The emul- packages aren't a very good solution for a number of
>> > > > reasons.
>> > > >
>> > > > I'd like to add multilib USE flags to Mesa and thus its dependencies.
>> > > > I realized that almost everything in x11-libs/ could be converted very
>> > > > easily, which would allow us to get rid of emul-linux-x86-xlibs in
>> > > > addition to emul-linux-x86-opengl.
>> > > >
>> > > >
>> > >
>> > > This looks like a shortened duplication of a subset of multilib-portage
>> > > features. While this wont hurt multilib-portage (since it does exclude
>> > > most actions on ebuilds with USE=multilib), it will mean a rewrite for
>> > > many ebuilds, which then again need another rewrite (or more likely
>> > > revert), when multilib-portage is accepted in a future EAPI.
>> >
>> > s/when/if/
>> >
>> > > So i would prefer some help/support with multilib-portage to get it
>> > > accepted sooner, instead of this additional workaround for a subset of
>> > > packages.
>> >
>> > I prefer the simpler solution.
>> >
>> > > P.S.: I know, that users, who want up-to-date 32bit drivers for games
>> > > and wine do use multilib-portage, so we already have a working solution
>> > > for this issue.
>> >
>> > They will no longer have to do that.
>> >
>>
>> I would prefer if eclass way could be extended to packages not using
>> autotools too, otherwise, we will still need emul packages for, for
>> example, qt libs. If that would be possible via eclass, maybe
>> multilib-portage wouldn't be needed but, if not, we will still need it
>> and, then, would be nice if this inclussion for autotools packages
>> wouldn't cause more problems to get the "strong" solution land in the
>> "near" future :/
>>
>> The simpler solution (eclass) looks fine to me, but it would need to be
>> extended to more packages than autotools based ones to let it replace
>> portage-multilib/emul packages
>
> Qt uses cmake, doesn't it?

No, it uses qmake, its own make tool. See qt4-build and qt4-r2 eclasses.
KDE and a number of other reverse dependencies of the Qt libs do use cmake.

> I don't mind having cmake-multilib as well? We could probably move
> the foreach_abi() function to some more common eclass, like multilib
> eclass.
>
> --
> Best regards,
> Michał Górny



-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Thomas Sachau]

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

Pacho Ramos schrieb:
> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
>> On Sun, 23 Sep 2012 11:07:30 +0200
>> Thomas Sachau <tommy@gentoo.org> wrote:
>>
>>> Matt Turner schrieb:
>>>> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>>>> It is a simple eclass using autotools out-of-source builds to build
>>>>> packages for multiple ABIs when multilib is supported.
>>>>
>>>> Thanks a lot, Michał! This looks good to me.
>>>>
>>>>> Use case: xorg packages, ask Matt.
>>>>
>>>> So the idea is that users want up-to-date 32-bit drivers for games and
>>>> WINE. The emul- packages aren't a very good solution for a number of
>>>> reasons.
>>>>
>>>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
>>>> I realized that almost everything in x11-libs/ could be converted very
>>>> easily, which would allow us to get rid of emul-linux-x86-xlibs in
>>>> addition to emul-linux-x86-opengl.
>>>>
>>>>
>>>
>>> This looks like a shortened duplication of a subset of multilib-portage
>>> features. While this wont hurt multilib-portage (since it does exclude
>>> most actions on ebuilds with USE=multilib), it will mean a rewrite for
>>> many ebuilds, which then again need another rewrite (or more likely
>>> revert), when multilib-portage is accepted in a future EAPI.
>>
>> s/when/if/
>>
>>> So i would prefer some help/support with multilib-portage to get it
>>> accepted sooner, instead of this additional workaround for a subset of
>>> packages.
>>
>> I prefer the simpler solution.
>>
>>> P.S.: I know, that users, who want up-to-date 32bit drivers for games
>>> and wine do use multilib-portage, so we already have a working solution
>>> for this issue.
>>
>> They will no longer have to do that.
>>
> 
> I would prefer if eclass way could be extended to packages not using
> autotools too, otherwise, we will still need emul packages for, for
> example, qt libs. If that would be possible via eclass, maybe
> multilib-portage wouldn't be needed but, if not, we will still need it
> and, then, would be nice if this inclussion for autotools packages
> wouldn't cause more problems to get the "strong" solution land in the
> "near" future :/
> 
> The simpler solution (eclass) looks fine to me, but it would need to be
> extended to more packages than autotools based ones to let it replace
> portage-multilib/emul packages
> 

you mean something like this one?

https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass

That was the original eclass allowing cross-compile support, but
required ebuilds to inherit it. multilib-portage is based on this, but
does not require to modify the ebuilds themselves.

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

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

El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió:
> Pacho Ramos schrieb:
> > El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
> >> On Sun, 23 Sep 2012 11:07:30 +0200
> >> Thomas Sachau <tommy@gentoo.org> wrote:
> >>
> >>> Matt Turner schrieb:
> >>>> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
> >>>>> It is a simple eclass using autotools out-of-source builds to build
> >>>>> packages for multiple ABIs when multilib is supported.
> >>>>
> >>>> Thanks a lot, Michał! This looks good to me.
> >>>>
> >>>>> Use case: xorg packages, ask Matt.
> >>>>
> >>>> So the idea is that users want up-to-date 32-bit drivers for games and
> >>>> WINE. The emul- packages aren't a very good solution for a number of
> >>>> reasons.
> >>>>
> >>>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
> >>>> I realized that almost everything in x11-libs/ could be converted very
> >>>> easily, which would allow us to get rid of emul-linux-x86-xlibs in
> >>>> addition to emul-linux-x86-opengl.
> >>>>
> >>>>
> >>>
> >>> This looks like a shortened duplication of a subset of multilib-portage
> >>> features. While this wont hurt multilib-portage (since it does exclude
> >>> most actions on ebuilds with USE=multilib), it will mean a rewrite for
> >>> many ebuilds, which then again need another rewrite (or more likely
> >>> revert), when multilib-portage is accepted in a future EAPI.
> >>
> >> s/when/if/
> >>
> >>> So i would prefer some help/support with multilib-portage to get it
> >>> accepted sooner, instead of this additional workaround for a subset of
> >>> packages.
> >>
> >> I prefer the simpler solution.
> >>
> >>> P.S.: I know, that users, who want up-to-date 32bit drivers for games
> >>> and wine do use multilib-portage, so we already have a working solution
> >>> for this issue.
> >>
> >> They will no longer have to do that.
> >>
> > 
> > I would prefer if eclass way could be extended to packages not using
> > autotools too, otherwise, we will still need emul packages for, for
> > example, qt libs. If that would be possible via eclass, maybe
> > multilib-portage wouldn't be needed but, if not, we will still need it
> > and, then, would be nice if this inclussion for autotools packages
> > wouldn't cause more problems to get the "strong" solution land in the
> > "near" future :/
> > 
> > The simpler solution (eclass) looks fine to me, but it would need to be
> > extended to more packages than autotools based ones to let it replace
> > portage-multilib/emul packages
> > 
> 
> you mean something like this one?
> 
> https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass
> 
> That was the original eclass allowing cross-compile support, but
> required ebuilds to inherit it. multilib-portage is based on this, but
> does not require to modify the ebuilds themselves.
> 

Yes, that is what I meant... but I don't find hard to modify ebuilds to
inherit it :/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Thomas Sachau]

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

Pacho Ramos schrieb:
> El dom, 23-09-2012 a las 13:52 +0200, Thomas Sachau escribió:
>> Pacho Ramos schrieb:
>>> El dom, 23-09-2012 a las 11:56 +0200, Michał Górny escribió:
>>>> On Sun, 23 Sep 2012 11:07:30 +0200
>>>> Thomas Sachau <tommy@gentoo.org> wrote:
>>>>
>>>>> Matt Turner schrieb:
>>>>>> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>>>>>> It is a simple eclass using autotools out-of-source builds to build
>>>>>>> packages for multiple ABIs when multilib is supported.
>>>>>>
>>>>>> Thanks a lot, Michał! This looks good to me.
>>>>>>
>>>>>>> Use case: xorg packages, ask Matt.
>>>>>>
>>>>>> So the idea is that users want up-to-date 32-bit drivers for games and
>>>>>> WINE. The emul- packages aren't a very good solution for a number of
>>>>>> reasons.
>>>>>>
>>>>>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
>>>>>> I realized that almost everything in x11-libs/ could be converted very
>>>>>> easily, which would allow us to get rid of emul-linux-x86-xlibs in
>>>>>> addition to emul-linux-x86-opengl.
>>>>>>
>>>>>>
>>>>>
>>>>> This looks like a shortened duplication of a subset of multilib-portage
>>>>> features. While this wont hurt multilib-portage (since it does exclude
>>>>> most actions on ebuilds with USE=multilib), it will mean a rewrite for
>>>>> many ebuilds, which then again need another rewrite (or more likely
>>>>> revert), when multilib-portage is accepted in a future EAPI.
>>>>
>>>> s/when/if/
>>>>
>>>>> So i would prefer some help/support with multilib-portage to get it
>>>>> accepted sooner, instead of this additional workaround for a subset of
>>>>> packages.
>>>>
>>>> I prefer the simpler solution.
>>>>
>>>>> P.S.: I know, that users, who want up-to-date 32bit drivers for games
>>>>> and wine do use multilib-portage, so we already have a working solution
>>>>> for this issue.
>>>>
>>>> They will no longer have to do that.
>>>>
>>>
>>> I would prefer if eclass way could be extended to packages not using
>>> autotools too, otherwise, we will still need emul packages for, for
>>> example, qt libs. If that would be possible via eclass, maybe
>>> multilib-portage wouldn't be needed but, if not, we will still need it
>>> and, then, would be nice if this inclussion for autotools packages
>>> wouldn't cause more problems to get the "strong" solution land in the
>>> "near" future :/
>>>
>>> The simpler solution (eclass) looks fine to me, but it would need to be
>>> extended to more packages than autotools based ones to let it replace
>>> portage-multilib/emul packages
>>>
>>
>> you mean something like this one?
>>
>> https://github.com/sjnewbury/multilib-overlay/blob/80c9fd20cfd05481ac19edcadd56ad5e578a8930/eclass/multilib-native.eclass
>>
>> That was the original eclass allowing cross-compile support, but
>> required ebuilds to inherit it. multilib-portage is based on this, but
>> does not require to modify the ebuilds themselves.
>>
> 
> Yes, that is what I meant... but I don't find hard to modify ebuilds to
> inherit it :/
> 

It is not hard by itself to inherit an eclass. There is just the
limitation, that occurs with an eclass, e.g.:

-the one from mgorny only does it for autotools based ebuilds only and
even there only for libraries, headers and binaries are not done. While
one may create the same for cmake based ones, those are still only for a
subset of packages, since not all do use autotools/cmake or are
satisfied with a libs only solution
-the multilib-native eclass does extend it way more, but still has its
limitations, e.g. what happens with a new target ABI (like x32 on the
amd64 profile) or how are dependencies handled?

multilib-portage is the answer to those limitations, since it does work
for any target with multilib cross-compile support, can handle things
like the dependencies internally and can even work on not
prepared/modified ebuilds.

So before i invest even more time in getting this official, we should
better get to some conclusion, if we either go the route with eclass
based multilib cross-compile support with its limitations or if we move
this up to the package manager level.

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Sun, 23 Sep 2012 16:49:13 +0200
Thomas Sachau <tommy@gentoo.org> wrote:

> It is not hard by itself to inherit an eclass. There is just the
> limitation, that occurs with an eclass, e.g.:
> 
> -the one from mgorny only does it for autotools based ebuilds only and
> even there only for libraries, headers and binaries are not done.
> While one may create the same for cmake based ones, those are still
> only for a subset of packages, since not all do use autotools/cmake
> or are satisfied with a libs only solution
> -the multilib-native eclass does extend it way more, but still has its
> limitations, e.g. what happens with a new target ABI (like x32 on the
> amd64 profile) or how are dependencies handled?
> 
> multilib-portage is the answer to those limitations, since it does
> work for any target with multilib cross-compile support, can handle
> things like the dependencies internally and can even work on not
> prepared/modified ebuilds.
> 
> So before i invest even more time in getting this official, we should
> better get to some conclusion, if we either go the route with eclass
> based multilib cross-compile support with its limitations or if we
> move this up to the package manager level.
> 

Can't we get something in between ?

Unless I'm mistaken, portage-multilib has its limitations also:

- I have package foo and package bar, both depending on ffmpeg and
canditates for a multilib build. However, package foo does not link to
ffmpeg but simply spawns the 'ffmpeg' binary to process some files,
package bar links to libavcodec. You need ffmpeg[multilib] for a
multilib build of bar but not for foo. How do you distinguish between
the two ?

- When an out-of-tree build is possible, it is more efficient to do it
  that way while multilib-portage will probably run the full src_*
  phases twice. mgorny's eclass is a solution to this for
  autotools-utils based ebuilds. I have added basic support for this in
  freebsd-lib some time ago also.



However, it is clear that USE=multilib is limited too. What we probably
need, as I read in the draft you posted some time ago, is a
MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an
eclass, add them to IUSE of multilib-enabled packages and then you can
use the USE-deps. When a new ABI gets added, add it to the list in the
eclass and be done. You already have PM support for this :)

You can leverage the generic multilib building code you have to an
eclass, so that you don't need to spec it; spec-ing it has its problems
too: what happens if next year pkg-config is deprecated and now we
shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not
FOO_CONFIG_PATH. You probably need a small EAPI change to be able to
implement sanely a generic solution into an eclass though.

My question to you would be: what are we missing from current EAPIs to
be able to perfectly support multilib builds ?

A.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

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

El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió:
> On Sun, 23 Sep 2012 16:49:13 +0200
> Thomas Sachau <tommy@gentoo.org> wrote:
> 
> > It is not hard by itself to inherit an eclass. There is just the
> > limitation, that occurs with an eclass, e.g.:
> > 
> > -the one from mgorny only does it for autotools based ebuilds only and
> > even there only for libraries, headers and binaries are not done.
> > While one may create the same for cmake based ones, those are still
> > only for a subset of packages, since not all do use autotools/cmake
> > or are satisfied with a libs only solution
> > -the multilib-native eclass does extend it way more, but still has its
> > limitations, e.g. what happens with a new target ABI (like x32 on the
> > amd64 profile) or how are dependencies handled?
> > 
> > multilib-portage is the answer to those limitations, since it does
> > work for any target with multilib cross-compile support, can handle
> > things like the dependencies internally and can even work on not
> > prepared/modified ebuilds.
> > 
> > So before i invest even more time in getting this official, we should
> > better get to some conclusion, if we either go the route with eclass
> > based multilib cross-compile support with its limitations or if we
> > move this up to the package manager level.
> > 
> 
> Can't we get something in between ?
> 
> Unless I'm mistaken, portage-multilib has its limitations also:
> 
> - I have package foo and package bar, both depending on ffmpeg and
> canditates for a multilib build. However, package foo does not link to
> ffmpeg but simply spawns the 'ffmpeg' binary to process some files,
> package bar links to libavcodec. You need ffmpeg[multilib] for a
> multilib build of bar but not for foo. How do you distinguish between
> the two ?
> 
> - When an out-of-tree build is possible, it is more efficient to do it
>   that way while multilib-portage will probably run the full src_*
>   phases twice. mgorny's eclass is a solution to this for
>   autotools-utils based ebuilds. I have added basic support for this in
>   freebsd-lib some time ago also.
> 
> 
> 
> However, it is clear that USE=multilib is limited too. What we probably
> need, as I read in the draft you posted some time ago, is a
> MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an
> eclass, add them to IUSE of multilib-enabled packages and then you can
> use the USE-deps. When a new ABI gets added, add it to the list in the
> eclass and be done. You already have PM support for this :)
> 
> You can leverage the generic multilib building code you have to an
> eclass, so that you don't need to spec it; spec-ing it has its problems
> too: what happens if next year pkg-config is deprecated and now we
> shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not
> FOO_CONFIG_PATH. You probably need a small EAPI change to be able to
> implement sanely a generic solution into an eclass though.
> 
> My question to you would be: what are we missing from current EAPIs to
> be able to perfectly support multilib builds ?
> 
> A.
> 
> 

What finally occurred with this? What would be the problem of opting by
this "mixed" solution (eclass for some packages and PM features
requiring newer eapi for others)?

Thanks

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Thomas Sachau]

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

Pacho Ramos schrieb:
> El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió:
>> On Sun, 23 Sep 2012 16:49:13 +0200
>> Thomas Sachau <tommy@gentoo.org> wrote:
>>
>>> It is not hard by itself to inherit an eclass. There is just the
>>> limitation, that occurs with an eclass, e.g.:
>>>
>>> -the one from mgorny only does it for autotools based ebuilds only and
>>> even there only for libraries, headers and binaries are not done.
>>> While one may create the same for cmake based ones, those are still
>>> only for a subset of packages, since not all do use autotools/cmake
>>> or are satisfied with a libs only solution
>>> -the multilib-native eclass does extend it way more, but still has its
>>> limitations, e.g. what happens with a new target ABI (like x32 on the
>>> amd64 profile) or how are dependencies handled?
>>>
>>> multilib-portage is the answer to those limitations, since it does
>>> work for any target with multilib cross-compile support, can handle
>>> things like the dependencies internally and can even work on not
>>> prepared/modified ebuilds.
>>>
>>> So before i invest even more time in getting this official, we should
>>> better get to some conclusion, if we either go the route with eclass
>>> based multilib cross-compile support with its limitations or if we
>>> move this up to the package manager level.
>>>
>>
>> Can't we get something in between ?
>>
>> Unless I'm mistaken, portage-multilib has its limitations also:
>>
>> - I have package foo and package bar, both depending on ffmpeg and
>> canditates for a multilib build. However, package foo does not link to
>> ffmpeg but simply spawns the 'ffmpeg' binary to process some files,
>> package bar links to libavcodec. You need ffmpeg[multilib] for a
>> multilib build of bar but not for foo. How do you distinguish between
>> the two ?

I dont really understand your question here. So do you:

- simply have 2 64bit apps wanting to use ffmpeg?
- have 2 32bit binary packages wanting to use ffmpeg?
- want to build foo and bar on a 64bit platform for a 32bit platform?
- want a 64bit or a 32bit version of ffmpeg or both?
- if you want a 32bit version of ffmpeg, do you only want 32bit libs or
also a 32bit binary?

>> - When an out-of-tree build is possible, it is more efficient to do it
>>   that way while multilib-portage will probably run the full src_*
>>   phases twice. mgorny's eclass is a solution to this for
>>   autotools-utils based ebuilds. I have added basic support for this in
>>   freebsd-lib some time ago also.

Isnt "out-of-tree build" just building in a seperate location, so in the
end doing one unpack instead of 2, while everything else still needs to
be done for each target?

>>
>>
>>
>> However, it is clear that USE=multilib is limited too. What we probably
>> need, as I read in the draft you posted some time ago, is a
>> MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an
>> eclass, add them to IUSE of multilib-enabled packages and then you can
>> use the USE-deps. When a new ABI gets added, add it to the list in the
>> eclass and be done. You already have PM support for this :)

Please keep in mind, that the USE flags are different, depending on your
arch. E.g. on amd64, you may additionally have x86 and x32, while on
ppc64, you may have ppc64 and ppc. You dont want the later on amd64 nor
the first on ppc. So how do you want to add different (use-expanded) USE
flags based on the arch the user is running?

>>
>> You can leverage the generic multilib building code you have to an
>> eclass, so that you don't need to spec it; spec-ing it has its problems
>> too: what happens if next year pkg-config is deprecated and now we
>> shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not
>> FOO_CONFIG_PATH. You probably need a small EAPI change to be able to
>> implement sanely a generic solution into an eclass though.
>>
>> My question to you would be: what are we missing from current EAPIs to
>> be able to perfectly support multilib builds ?

While the variable export, the build for each target and the merge of
the results should also be possible inside an eclass, the dependency and
USE flag parts seems more tricky.

And additionally, with support of this in (multilib-)portage (not
depending on EAPI, but enabled via FEATURES), i already get all of this
without having to wait for a new EAPI/eclass and ebuilds moving to it.


> What finally occurred with this? What would be the problem of opting by
> this "mixed" solution (eclass for some packages and PM features
> requiring newer eapi for others)?

I guess nothing new. Nobody yet provided an eclass providing the full
support for everything i have in multilib-portage and i did not create
the requested PMS-diff yet.


-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Alexis Ballier]

On Thu, 03 Jan 2013 11:44:58 +0100
Thomas Sachau <tommy@gentoo.org> wrote:

> Pacho Ramos schrieb:
> > El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió:
> >> On Sun, 23 Sep 2012 16:49:13 +0200
> >> Thomas Sachau <tommy@gentoo.org> wrote:
> >>
> >>> It is not hard by itself to inherit an eclass. There is just the
> >>> limitation, that occurs with an eclass, e.g.:
> >>>
> >>> -the one from mgorny only does it for autotools based ebuilds
> >>> only and even there only for libraries, headers and binaries are
> >>> not done. While one may create the same for cmake based ones,
> >>> those are still only for a subset of packages, since not all do
> >>> use autotools/cmake or are satisfied with a libs only solution
> >>> -the multilib-native eclass does extend it way more, but still
> >>> has its limitations, e.g. what happens with a new target ABI
> >>> (like x32 on the amd64 profile) or how are dependencies handled?
> >>>
> >>> multilib-portage is the answer to those limitations, since it does
> >>> work for any target with multilib cross-compile support, can
> >>> handle things like the dependencies internally and can even work
> >>> on not prepared/modified ebuilds.
> >>>
> >>> So before i invest even more time in getting this official, we
> >>> should better get to some conclusion, if we either go the route
> >>> with eclass based multilib cross-compile support with its
> >>> limitations or if we move this up to the package manager level.
> >>>
> >>
> >> Can't we get something in between ?
> >>
> >> Unless I'm mistaken, portage-multilib has its limitations also:
> >>
> >> - I have package foo and package bar, both depending on ffmpeg and
> >> canditates for a multilib build. However, package foo does not
> >> link to ffmpeg but simply spawns the 'ffmpeg' binary to process
> >> some files, package bar links to libavcodec. You need
> >> ffmpeg[multilib] for a multilib build of bar but not for foo. How
> >> do you distinguish between the two ?
> 
> I dont really understand your question here. So do you:
> 
> - simply have 2 64bit apps wanting to use ffmpeg?
> - have 2 32bit binary packages wanting to use ffmpeg?
> - want to build foo and bar on a 64bit platform for a 32bit platform?
> - want a 64bit or a 32bit version of ffmpeg or both?
> - if you want a 32bit version of ffmpeg, do you only want 32bit libs
> or also a 32bit binary?


it depends on what you are building; let's say we want all abi flavors
for foo and bar.

in the above example, package foo uses fork/exec so needs a libc
compatible with its abis and that's all; it doesn't care if ffmpeg is
an elf executable, a bash script, or running through an emulator.
package bar needs ffmpeg libraries for every abi it installs.
portage multilib doesn't seem to distinguish between the two cases.

> >> - When an out-of-tree build is possible, it is more efficient to
> >> do it that way while multilib-portage will probably run the full
> >> src_* phases twice. mgorny's eclass is a solution to this for
> >>   autotools-utils based ebuilds. I have added basic support for
> >> this in freebsd-lib some time ago also.
> 
> Isnt "out-of-tree build" just building in a seperate location, so in
> the end doing one unpack instead of 2, while everything else still
> needs to be done for each target?

yes, so?
(unpack in the EAPI0 sense btw, prepare shouldn't need to be done twice
either)

> >> However, it is clear that USE=multilib is limited too. What we
> >> probably need, as I read in the draft you posted some time ago, is
> >> a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in
> >> an eclass, add them to IUSE of multilib-enabled packages and then
> >> you can use the USE-deps. When a new ABI gets added, add it to the
> >> list in the eclass and be done. You already have PM support for
> >> this :)
> 
> Please keep in mind, that the USE flags are different, depending on
> your arch. E.g. on amd64, you may additionally have x86 and x32,
> while on ppc64, you may have ppc64 and ppc. You dont want the later
> on amd64 nor the first on ppc. So how do you want to add different
> (use-expanded) USE flags based on the arch the user is running?

no, the useflags are not different:

coma=""
for i in $MULTILIB_ABIS ; do
    multilib_use_deps+="${coma}multilib_abi_${i}?"
    coma=", "
done

deps like foo[multilib?] becomes foo[${multilib_use_deps}]
and voila, you are not anymore limited to multilib or not multilib but
really control the abis.

> >> You can leverage the generic multilib building code you have to an
> >> eclass, so that you don't need to spec it; spec-ing it has its
> >> problems too: what happens if next year pkg-config is deprecated
> >> and now we shall all use foo-config ? your spec adjusts
> >> PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small
> >> EAPI change to be able to implement sanely a generic solution into
> >> an eclass though.
> >>
> >> My question to you would be: what are we missing from current
> >> EAPIs to be able to perfectly support multilib builds ?
> 
> While the variable export, the build for each target and the merge of
> the results should also be possible inside an eclass, the dependency
> and USE flag parts seems more tricky.

Even with what I've written above ? Why ?

> And additionally, with support of this in (multilib-)portage (not
> depending on EAPI, but enabled via FEATURES), i already get all of
> this without having to wait for a new EAPI/eclass and ebuilds moving
> to it.

You don't need an EAPI then, just get your changes merged in portage.

Alexis.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Michał Górny]

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

On Mon, 14 Jan 2013 15:04:45 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Thu, 03 Jan 2013 11:44:58 +0100
> Thomas Sachau <tommy@gentoo.org> wrote:
> 
> > Please keep in mind, that the USE flags are different, depending on
> > your arch. E.g. on amd64, you may additionally have x86 and x32,
> > while on ppc64, you may have ppc64 and ppc. You dont want the later
> > on amd64 nor the first on ppc. So how do you want to add different
> > (use-expanded) USE flags based on the arch the user is running?
> 
> no, the useflags are not different:
> 
> coma=""
> for i in $MULTILIB_ABIS ; do
>     multilib_use_deps+="${coma}multilib_abi_${i}?"
>     coma=", "
> done
> 
> deps like foo[multilib?] becomes foo[${multilib_use_deps}]
> and voila, you are not anymore limited to multilib or not multilib but
> really control the abis.

Hmm, it may be a good idea to introduce such a variable already.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Peter Stuge]

Alexis Ballier wrote:
> - I have package foo and package bar, both depending on ffmpeg and
> canditates for a multilib build. However, package foo does not link to
> ffmpeg but simply spawns the 'ffmpeg' binary to process some files,
> package bar links to libavcodec. You need ffmpeg[multilib] for a
> multilib build of bar but not for foo. How do you distinguish between
> the two ?

foo.ebuild has RDEPEND=ffmpeg
bar.ebuild has DEPEND=ffmpeg[multilib?]

Right?


> - When an out-of-tree build is possible, it is more efficient to do it
>   that way while multilib-portage will probably run the full src_*
>   phases twice.

Certainly.


//Peter

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sun, Sep 23, 2012 at 2:07 AM, Thomas Sachau <tommy@gentoo.org> wrote:
> Matt Turner schrieb:
>> On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>> It is a simple eclass using autotools out-of-source builds to build
>>> packages for multiple ABIs when multilib is supported.
>>
>> Thanks a lot, Michał! This looks good to me.
>>
>>> Use case: xorg packages, ask Matt.
>>
>> So the idea is that users want up-to-date 32-bit drivers for games and
>> WINE. The emul- packages aren't a very good solution for a number of
>> reasons.
>>
>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
>> I realized that almost everything in x11-libs/ could be converted very
>> easily, which would allow us to get rid of emul-linux-x86-xlibs in
>> addition to emul-linux-x86-opengl.
>>
>>
>
> This looks like a shortened duplication of a subset of multilib-portage
> features. While this wont hurt multilib-portage (since it does exclude
> most actions on ebuilds with USE=multilib), it will mean a rewrite for
> many ebuilds, which then again need another rewrite (or more likely
> revert), when multilib-portage is accepted in a future EAPI.

I'd much rather have portage handle this for me as well.
Unfortunately, the last mail I see about multilib-portage is from two
months ago. If it were in EAPI 5, I'd be happy to wait for it. If it
even looked like it were progressing, I might wait. But, as you know,
gentoo-dev is where ideas go to die.

As far as ebuild conversions go, this is really simple.

> So i would prefer some help/support with multilib-portage to get it
> accepted sooner, instead of this additional workaround for a subset of
> packages.

That seems like a reasonable request. Let me re-read the previously
mentioned thread and get back to you.

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Pacho Ramos]

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

El sáb, 22-09-2012 a las 23:24 +0200, Michał Górny escribió:
> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.
> 
> Use case: xorg packages, ask Matt.
> ---
>  gx86/eclass/autotools-multilib.eclass | 72 +++++++++++++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
>  create mode 100644 gx86/eclass/autotools-multilib.eclass
> 
> diff --git a/gx86/eclass/autotools-multilib.eclass b/gx86/eclass/autotools-multilib.eclass
> new file mode 100644
> index 0000000..1a345a1
> --- /dev/null
> +++ b/gx86/eclass/autotools-multilib.eclass
> @@ -0,0 +1,72 @@
> +# Copyright 1999-2012 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header: $
> +
> +# @ECLASS: autotools-multilib.eclass
> +# @MAINTAINER:
> +# Michał Górny <mgorny@gentoo.org>
> +# @BLURB: autotools-utils wrapper for multilib builds
> +# @DESCRIPTION:
> +# The autotools-multilib.eclass is an autotools-utils.eclass(5) wrapper
> +# introducing support for building for more than one ABI (multilib).
> +#
> +# Inheriting this eclass sets IUSE=multilib and exports autotools-utils
> +# phase function wrappers which build the package for each supported ABI
> +# if the flag is enabled. Otherwise, it works like regular
> +# autotools-utils.
[...]

One problem that I remembered now:
If every ebuild inheritting this eclass (either this one or similar)
will add a "multilib" USE, people running multilib profiles will get it
enabled for ALL packages inheritting it, causing them to see how their
systems grow a lot because they will have 32bits libs for all packages,
even when not needed. For example, in my systems I need gtk+ 32 bits
libs, but not qt ones as I don't have any qt based app requiring 32bits
installed.

Maybe the way to workaround this would be to rename it to something like
"32bits", that way if, for example, acroread RDEPENDs on gtk+[32bits],
it would only be enabled for needed packages not all

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

[Matt Turner]

On Sun, Sep 23, 2012 at 5:30 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> One problem that I remembered now:
> If every ebuild inheritting this eclass (either this one or similar)
> will add a "multilib" USE, people running multilib profiles will get it
> enabled for ALL packages inheritting it, causing them to see how their
> systems grow a lot because they will have 32bits libs for all packages,
> even when not needed. For example, in my systems I need gtk+ 32 bits
> libs, but not qt ones as I don't have any qt based app requiring 32bits
> installed.

Currently, yes, that is the case.

The fix is pretty simple though, and is in progress:
https://bugs.gentoo.org/show_bug.cgi?id=435094 (previously mentioned
in this thread...)