Bugzilla Bug 66478

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 an attachment (id=41191) [edit]
patch for ac-wrapper-4.pl

Created an attachment (id=41192) [edit]
patch for am-wrapper.pl-1.8-v2

Created an attachment (id=41193) [edit]
plain ac-wrapper.pl

Created an attachment (id=41194) [edit]
plain am-wrapper.pl

Created an attachment (id=41195) [edit]
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 an attachment (id=42738) [edit]
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 an attachment (id=42882) [edit]
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 an attachment (id=42883) [edit]
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 an attachment (id=43350) [edit]
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 an attachment (id=43351) [edit]
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