-----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 <[email protected]>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----- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
