autotools-multilib: wrapper eclass for multilib builds.
 

"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?

autotools-multilib: wrapper eclass for multilib builds.
 

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

autotools-multilib: wrapper eclass for multilib builds.
 

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 :)

autotools-multilib: wrapper eclass for multilib builds.
 

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.

autotools-multilib: wrapper eclass for multilib builds.
 

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/

autotools-multilib: wrapper eclass for multilib builds.
 

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.

autotools-multilib: wrapper eclass for multilib builds.
 

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

autotools-multilib: wrapper eclass for multilib builds.
 

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

autotools-multilib: wrapper eclass for multilib builds.
 

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

autotools-multilib: wrapper eclass for multilib builds.
 

-----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+POKWREDTH8ZWQaq3r1G4BeOH7IbxwuGrLmTUp36 oSpVRYX5XnXyl0
3MvRe9bXpih8exwOJudncc/4NFtX9c12wO6CifH0xKwcr7lu7k6jpRyfD3dIpXXq
QQlY4MjuCfy6aHxp+4+CvL9WEZ4cmkXxoi/EZCsMZYb+jBQ1NF0Jxr6tULX575vz
Vvm+n3sdTPMkh863vrAmglwFYtDgucmp/OeYZD03g3Ef52x1/NefkIGcwXGUjlY=
=FXgk
-----END PGP SIGNATURE-----