On Sun, 24 Feb 2013 16:12:18 +0100 Pacho Ramos <pa...@gentoo.org> wrote:
> El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
> [...]
> > > d) the previous point will also allow to convert go-mono.eclass packages
> > > without introducing yet another eclass for that
> >
> > So you're introducing a hacky eclass just because you're too lazy to
> > convert go-mono packages properly and too impatient to let others do
> > the work properly for you?
>
> Would be nice to know what autotools-utils.eclass is doing differently
> that is showing this problem with go-mono.eclass packages :/
I already told that I'm going to look at this but I have too much work
to do right now so it's going to take a longer while.
> Only one question, what is the reason for us having base.eclass and
> autotools-utils.eclass?
I think that base.eclass is silently intended for removal at some point
in the future. While we're here, we should probably mark it deprecated.
autotools-utils does a bit more -- especially by using out-of-source
builds. The major reason to use autotools-utils so far was to support
those builds.
Believe me or not, the day I took over the maintenance of it I seen
the opportunity to use out-of-source builds for multilib. Today, both
python-r1 & multilib-build were specifically designed to allow using
out-of-source builds with minimal effort.
> I still try to use plain ebuilds without
> inheritting autotools-utils.eclass as I usually don't need it, probably
> others do the same and refuse to have to inherit it only for multilib
> support :/ How do you plan to solve this problem?
You generally have two options on doing multilib builds: either using
out-of-source builds or in-source builds. If you decide on the latter,
you unnecessarily waste users' time and disk space to create two more
copies of sources. I don't think we should go this way.
If you decide on out-of-source builds, you basically need proper
src_{configure,compile,test,install} and that's what autotools-utils
does. Plus:
- prune_libtool_files in src_install() which most people want to do
anyway, so that doesn't hurt -- and the pkg-config dep is going to
be removed, by the patch I sent already.
- patch applying and autoreconf in src_prepare() -- which are
completely optional, you are free to write your own src_prepare().
If you wanted to apply patches by hand, you'd need to write
src_prepare() anyway.
- adding libtool args for shared/static libs if IUSE=static-libs --
which I wanted to remove but people considered it useful.
> I would also like to hear why that people refuses to use
> autotools-utils.eclass... because I don't have a strong opinion on this
> topic
Well, the major argument was similar to yours -- why we should use
an eclass if default PMS functions work. But in the multilib case, they
do not work by design anymore.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
