FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-23-2012, 12:30 PM
Michał Górny
 
Default autotools-multilib: wrapper eclass for multilib builds.

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
 
Old 09-23-2012, 12:30 PM
Pacho Ramos
 
Default autotools-multilib: wrapper eclass for multilib builds.

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
 
Old 09-23-2012, 02:49 PM
Thomas Sachau
 
Default autotools-multilib: wrapper eclass for multilib builds.

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
 
Old 09-23-2012, 03:47 PM
Alexis Ballier
 
Default autotools-multilib: wrapper eclass for multilib builds.

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.
 
Old 09-23-2012, 04:07 PM
Diego Elio Pettenò
 
Default autotools-multilib: wrapper eclass for multilib builds.

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/
 
Old 09-23-2012, 04:31 PM
Michał Górny
 
Default autotools-multilib: wrapper eclass for multilib builds.

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
 
Old 09-23-2012, 04:32 PM
Michał Górny
 
Default autotools-multilib: wrapper eclass for multilib builds.

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
 
Old 09-23-2012, 04:57 PM
Matt Turner
 
Default autotools-multilib: wrapper eclass for multilib builds.

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.
 
Old 09-23-2012, 05:01 PM
Matt Turner
 
Default autotools-multilib: wrapper eclass for multilib builds.

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.
 
Old 09-23-2012, 05:07 PM
Matt Turner
 
Default autotools-multilib: wrapper eclass for multilib builds.

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.
 

Thread Tools




All times are GMT. The time now is 03:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org