On Mon, 24 Sep 2012 19:32:14 +0200 Michał Górny <mgo...@gentoo.org> wrote:
> On Mon, 24 Sep 2012 12:17:58 -0300 > Alexis Ballier <aball...@gentoo.org> wrote: > > > On Sun, 23 Sep 2012 18:31:25 +0200 > > Michał Górny <mgo...@gentoo.org> wrote: > > > > > On Sun, 23 Sep 2012 12:47:44 -0300 > > > Alexis Ballier <aball...@gentoo.org> wrote: > > > > > > > On Sun, 23 Sep 2012 09:21:20 +0200 > > > > Michał Górny <mgo...@gentoo.org> wrote: > > > > > > > > > On Sat, 22 Sep 2012 21:46:02 -0300 > > > > > Alexis Ballier <aball...@gentoo.org> wrote: > > > > > > > > > > > On Sat, 22 Sep 2012 23:24:46 +0200 > > > > > > Michał Górny <mgo...@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.
