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