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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-03-10 15:21, Chris Larson wrote:
> 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?

I was about to create a class that did only gnu-config update +
oe_runconf but was too lazy this morning :)

But the more I think of it, the more I want autotools*.bbclass to
degrade to oe_runconf when encountering too new autoconf requirements.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLnlvaMkyGM64RGpERAiB4AJ9KTfM3rI7cygmG+PgxdTYOJRAdyQCdGtb8
j9TqonSN8vabkm06QQcviA4=
=3u0i
-----END PGP SIGNATURE-----