[oe] [RFC] Make autotools.bbclass warn and fixup for "needs newer autoconf" breakage

[Chris Larson]

On Mon, Mar 15, 2010 at 3:03 AM, Koen Kooi <k.kooi at student.utwente.nl>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Every now and then the world moves to a more recent autoconf (2.64 is
> popular nowadays) and distros in OE have to to through a lengthy
> test-fix-bump cycle to keep up. The workaround for such a problem
> usually is:
>
> do_configure() {
>        gnu-configize
>        oe_runconf
> }
>
> That gets us the config.guess for exotic targets (e.g. avr32) and runs
> the in-tree configure script. What are your opinions on adding something
> like this to autotools.bbclass:
>
> if ((needed autoconf > installed autoconf) && configure exists)
>        BIG FAT WARNING
>        skip libtoolize + reconf
>
> The biggest problem with that is that is "silently" degrades when using
> the "wrong autoconf" and the possibility for mismatched
> do_configure_prepend/append  methods.
>

It doesn't *necessarily* have to degrade silently -- you could do a check
from python, either in the task or in the taskstarted event handler for
do_configure.  (Aside: now that bitbake master can split into client/server,
bbnote/bberror/etc scripts that actually output stuff via bitbake rather
than in the logs should be a real possibility for that branch..)

Do the benefits (not littering recipes with global shortcuts) outweigh
> the downsides?


On the one hand, I like the idea, particularly if we can arrange some sort
of warning (or, alternatively, add a message to a sanity check task, so its
explicit).  The only minor concern I have with this is the fact that minimum
autoconf versions actually rarely reflect real dependency by upstream.  Most
commonly, they just injected the version number they use, not the one they
actually require.. of course, trying to catch those is a bit of a pain in
the ass, so it may be that this is best.  *shrug*

On a related note, I too dislike the recipe 'litter', and think that we need
a way to toggle non-autoreconf behavior from the recipe easily.  In the
autotools branch I started on but never completed, I pushed the common
autoconf bits into autotools_base.bbclass, and inheriting that rather than
autotools resulted in gnu-config update + oe_runconf, but an alternative
would be to just add a variable for it.  Thoughts on that?
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics