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, 05:10 PM
Matt Turner
 
Default autotools-multilib: wrapper eclass for multilib builds.

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...)
 
Old 09-23-2012, 07:16 PM
Zac Medico
 
Default autotools-multilib: wrapper eclass for multilib builds.

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
 
Old 09-24-2012, 03:18 AM
Ben de Groot
 
Default autotools-multilib: wrapper eclass for multilib builds.

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

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

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

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

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

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 ?
 
Old 09-24-2012, 08:47 PM
Michał Górny
 
Default autotools-multilib: wrapper eclass for multilib builds.

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

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
 

Thread Tools




All times are GMT. The time now is 11:42 AM.

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