The following patches change the ac-wrapper.pl and am-wrapper.pl scripts to use by default the most recent version of auto* tools (autoconf-2.59, automake-1.8 at the moment) instead of the ancient 2.13 and 1.4. This has little impact on the packages in the portage tree, because the wrappers do a very good job at detecting the version used to generate configure and Makefile.in, automatically choosing the correct version even without defining WANT_AUTOCONF/WANT_AUTOMAKE. The default comes into play mainly for newly created projects, when autotools run for the first time; since Gentoo is the platform of choice for a lot of software developers it is a good idea to stimulate the use of newer tools. Moreover, bug 56670, bug 58255 and newly created bug 66446 can take advantage of this change, and the code in the wrappers is a bit simplified. I did quite a lot of testing to ensure the rules are correct, while I found the current versions are not rock solid, for instance the rule in ac-wrapper.pl (cat_('configure') =~ /^# Generated by Autoconf (\S+)/m ? $1 : '') gt '2.13' is not correct (the text is a bit different and does not match).
Created attachment 41191 [details, diff] patch for ac-wrapper-4.pl
Created attachment 41192 [details, diff] patch for am-wrapper.pl-1.8-v2
Created attachment 41193 [details] plain ac-wrapper.pl
Created attachment 41194 [details] plain am-wrapper.pl
Created attachment 41195 [details, diff] patch for am-wrapper.pl-1.8-v2
autoconf-2.59-r6+ does this now
Out of curiosity: the new masked autoconf-wrapper brings back to the old deprecated syntax: WANT_AUTOCONF_2_1 (and changes WANT_AUTOCONF_2_5 to FORCE_AUTOCONF_2_5), is this the intended behavior for the future or is it just a work in progress? If the autoconf/automake stuff will be slotted, will it be responsability of the ebuild writers to depend on the right version? Doesn't this defeat the purpose of the autodetection logic?
the WANT_AUTOCONF= missing is a mistake, i grabbed the latest mdk wrapper since it handles things better but i missed the reversal of the envvar i'll port the syntax from the older wrapper forward as for the SLOTing thing, we may just make the wrapper DEPEND on all versions
In concept I do not have a problem with this, but you will have to a clean bootstrap & emerge system & emerge gnome kde whateverelse to verify that there are no regressions ... Mike, also please do not just use the latest MDK stuff .. we have a lot of fixes that they do not ...
like i mentioned before, i'm quite weak at perl ;) the new wrapper handled Bug 56670 correctly ... or it could just be because the new wrapper runs 2.5x by default ...
yes... as pointed out in comment #0 If anyone interested, I can repost my patches taking into account the updated mdk scripts. and now I'm going do the bootstrap test...
For interest sake, what is new in the latest MDK scripts btw? They bitched about me not sending them fixes, but then when I did never bothered to use it. Oh, and do they actually have an am-wrapper.pl now? They did not use to have ...
i was only able to find an updated ac-wrapper via src rpms on some rpmfind sites ... wasnt able to find traces of am-wrapper anywhere at all, let alone an upstream cvs site or something from what i could tell, ac-wrapper had these changed behaviors: - better parsing for required versions - no more support for WANT_AUTOCONF_#_#=1 - change the order of selection from newest to oldest instead of oldest to newest
Mind attaching it to this bug?
Created attachment 42738 [details] ac-wrapper.pl http://rpm.pbone.net/index.php3/stat/4/idpl/1399863/com/autoconf2.5-2.59-6mdk.noarch.rpm.html this was the best i could find, grabbed the ac-wrapper.pl out of it
Seems they only really fix the check for the dubious: (cat_('configure') =~ /^# Generated by Autoconf (\S+)/m ? $1 : '') gt '2.13' and then they add some really nice error checking and consistent checking. Gregorio, I do not know if you want to take a stab at integrating some of the ideas in there, as it seems your perl might be better than mine (which is only slightly better than Mike's I *think*) ?
Created attachment 42882 [details] ac-wrapper-1.pl based on the mdk one > ... it seems your perl might be better than mine I don't think so... anyway, here's a version of the mdk script modified to respect the WANT_AUTOCONF=x.y syntax, and using a style consistent with am-wrapper.pl (will attach that in a minute...)
Created attachment 42883 [details] am-wrapper-1.pl based on the mdk one ... and here's a new am-wrapper.pl, created from the old one using the same style of ac-wrapper.pl, naturally using the WANT_AUTOMAKE=x.y syntax. Both the scripts have passed a fair round of testing. Note: I didn't reintroduce the code to stay comptible with the old WANT_AUTOCONF_x_y syntax. That could be added with no troubles, but I think it is convinient to just remove support for that: currently in the tree there are just two packages setting WANT_AUTOCONF_2_1: kde-functions.eclass and mozilla (a bunch of others use WANT_AUTOCONF_2_5, which is now useless), and there are 6 that use WANT_AUTOMAKE_1_x: kde-functions.eclass, cyrus-sasl, vlc, drip, texinfo, libtool; all these could be changed by hand in a minute. But the decision is up to you.
Looks good. I was thinking it might be a good idea to see if the old value is in use, and then error out? Should make sure it dies a good death. Mike, can you possibly get time to fix the tree of the old syntax ?
yep, i'll start checkin now
all set now
you know, someone just pointed out something that was kind of obvious ... why dont we just rewrite this frickin things in bash ? the wrapper is pretty simple, not a lot of hard logic here ... the core guys can all handle bash/awk/sed/etc... easily (instead of perl) ... and, we wont have to try to keep our crap in sync with mdk ... it's already proven to be a hassle so what do you guys think ?
Created attachment 43350 [details] ac-wrapper-1.sh Ok, what about this? it calls perl to match the regexp, but it's just one line. The same thing with awk will look like this: awk '{ if (match($0, "^# Generated (by (GNU )?Autoconf|automatically using autoconf version) ([0-9].[0-9])", res)) { print res[3]; exit } }' configure ugly, isn't it?
Created attachment 43351 [details] am-wrapper-1.sh and here's the brother script
I am pretty sure it will be faster if we just used perl, instead of bash calling perl (bash is slow to begin with, now you have it calling perl). Just my thoughts anyhow ...
that may be true, but in the larger scheme of things, how much of an overhead would it inflict ? i'm sure the large majority of time will be spent in the actual autoconf/automake scripts and the overhead for using bash instead of perl is negligible the call to perl can be rewritten in 'proper' shell (as pointed out by Gregorio) ... perhaps we could touch it up to make it less ugly :) the biggest gain here is the level of competence required to fix the script ... simple fact, the core guys all know bash inside and out a lot less of us know perl (some even at all :p)
I guess I will be more comfortable with bash/awk as well.
ok, new bash versions are in cvs, thanks :) please file new bugs if the new bash versions have bugs ... i'm running some tests locally now
