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

[Frans Meulenbroeks]

2010/3/15 Chris Larson <clarson at kergoth.com>:
> 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?

According to the handbook using classes to separate common
functionality is good (http://docs.openemb
edded.org/usermanual/html/recipes_classes.html)
and I tend to agree with that.

What would be nice is if adjacent to being implemented, it would
(preferably at the same time) be documented somewhere.
I see lots of variables in recipes for which the only way to find out
is to dig into the classes and see how they are used.
(and actually yesterday I removed an unused/egacy var from all recipes
in my branch. Didn't make the change in dev head, as I don't feel
getting the wrath of some people upon me, even though the change is
good).

Frans.