On Thu, 7 Jul 2005 02:04:04 +0200
Sven Wegener <[EMAIL PROTECTED]> wrote:
> We would like to split up src_compile. The new src_configure
> should just do the econf part and src_compile should do the
> emake part.
Just by curiosity, i've run a grep on the tree to count occurences
of "^[[:space:]]*econf" and "^[[:space:]]*\..*/configure" in
ebuilds. Here are the results (that's numbers of ebuilds, not
packages, grouped by the number of econf/configure they have):
1: 5736
2: 182
3: 12
4: 3
5: 2
7: 3
I would have thought this figures would be much worst, but that's
actually a few tenths of packages with 2 config calls, and only
~10 with 3+.
Looking at some random ebuilds with 2+ econf/configure, it seems
that the most frequent pattern is something like that:
====================================================
src_compile() {
econf || die
emake || die
if use foo ; then
cd "${S}/foo-plugin"
econf || die
emake || die
fi
}
====================================================
Sure, spliting that will produce a bit of code duplication. It's
a bit less readable imho, but that's really just a cosmetic
issue:
====================================================
src_configure() {
econf || die
if use foo ; then
cd "${S}/foo-plugin"
econf || die
fi
}
src_compile() {
emake || die
if use foo ; then
cd "${S}/foo-plugin"
emake || die
fi
}
====================================================
I've also searched for some more problematic ebuilds, like some
which would configure & build the same source several times
(x11-libs/wxGTK maybe, also i'm not really sure) or some which
would first configure and build a libfoo/ subtree, and then
configure and build the main program (did not found any of that
kind, but i would not be surprised some exists).
If anyone want to have a look on my list to find some package
that may be problematic, it's here:
http://tdegreni.free.fr/gentoo/ebuilds_with_two_or_more_configure.list
(disclaimer: yup, keep in mind i've just done a quick grep on
the tree - this figures might not be completly meaningless, but
are for sure not accurate)
--
TGL.
--
[email protected] mailing list
