Improvement to admin/detect-autoconf.sh [PATCH]

[Michael Pyne]

Hi all,

A FreeBSD user had reported an error against kdesvn-build, and gave me access 
to a FreeBSD box to investigate.  After my investigation I came to the 
conclusion that it would probably be a good idea to update 
detect-autoconf.sh.  The reasons?

 1. New versions of automake and autoconf have to be added to the script as 
they are released.  So if a user upgrades the autotools to a version that is 
(presumably) better, it won't be picked up until we update the autotools.

 2. Some operating systems (notably, the FreeBSD box I have access to), have 
the autotools installed but with a different versioning scheme.  e.g. even 
though detect-autoconf.sh will search for autoconf-2.53, it will never find 
FreeBSD's autoconf253 script.

So, I went and created a Perl script to do a rather exhaustive search for the 
autotools.  Since I was at it (and it wasn't hard) I added a few things.

 1. It searches for the best installed executable version of automake and 
autoconf, and uses the version number it reads from the script to search for 
aclocal, autom4te, and autoheader just like detect-autoconf.sh does.  If 
there is no versioned script in $PATH then it will use a non-versioned script 
if available (e.g. if "automake" is the only automake* in the PATH it will 
use that).  This is also the same as the current detect-autoconf.sh, which 
seems to prefer versioned over unversioned scripts.

 2. When doing this search, it doesn't rely on a list of suffixes distributed 
with the script.  So, it will find the "best" version of auto* even if the 
user updates the autotools after downloading KDE.

 3. The programs it looks for (which, auto*, unsermake) can be overridden by 
an environment variable of the same name uppercased.  UNSERMAKE=no is still 
checked for.  This way users don't have to setup symlinks to run make -f 
Makefile.cvs.

 4. The output is in an eval-able form for shell scripts.

 5. It works both on my Linux system and the FreeBSD box I have access to. :)

One potential problem is that the attached detect-autoconf.pl doesn't do 
blacklisting.  It's not hard for me to add, but do we need it?  Or if 
blacklisting is not required, should I add a minimum version to check for 
when looking for the tools?

Also, it's written in Perl, which I *think* is required for KDE building 
anyways.  I tried starting out in sh but it quickly drove me batty.  I can 
try to get help to convert it to sh if it's absolutely necessary however.

Note that I'm *not* saying that you can't build KDE on FreeBSD without this 
patch, or you would have heard whining from people besides me. ;-)  According 
to Adrian there is a gnu-autoconf and gnu-automake port for FreeBSD that 
provides the unversioned autotools that makes KDE from SVN work.  I just 
think that if there are autotools available it should be easier to have KDE 
use them (while we're still using the autotools. >:-)

Any and all comments are appreciated.

The following patch to cvs.sh is needed to use the script after it's placed in 
the /admin dir and made executable:

Index: cvs.sh
===================================================================
--- cvs.sh      (revision 435055)
+++ cvs.sh      (working copy)
@@ -628,8 +628,9 @@
   rm -f $makefile_wo
 fi

-# Suck in the AUTOCONF detection code
-. $admindir/detect-autoconf.sh
+# Call script to find autoconf and friends.  Uses eval since the script 
outputs
+# sh-compatible code.
+eval `$admindir/detect-autoconf.pl`

 ###
 ### Main

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: detect.pl
Type: application/x-perl
Size: 3748 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050716/4e8fff52/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050716/4e8fff52/attachment.sig>