tux

Sanitize your configure.ac

A while ago automake-1.13 (and soon after; automake-1.13.1) was released. I thought I'd make a quick update to version OpenEmbedded uses.
I soon learned that despite some automake macros having been deprecated for a very long time, many projects had not replaced them with proper ones. As some macros are completely removed from automake-1.13, it erroring out upon seeing those, automake fails for a lot of packages. There am I, trying to apply automake-1.13 to large portion of FOSS projects. I'm already close to fixing 50 packages broken that way. Fixing is trivial - it takes much more time to figure out where and how the project wants contributions to be submitted and then complying with those policies. It would be nice if I wouldn't need to do something similar when automake-1.14 comes out. Or some autoconf version removing macros, for that matter.
I know how easy it's not to notice when some macro you have always used gets merely deprecated in new autotools versions. Everything still works perfectly even though you are living on the time when old and new methods work, overlap, and should be preparing things for the future when only the new way will remain. But autotools provide tool named 'autoupdate'. Someone in the project to run it once every year or two to check if something in configure.ac (I hope that's configure.ac, and not long deprecated name configure.in) needs updating wouldn't require too much effort, I think. Just take backup of your current configure.ac, run autoupdate, and compare your backup version to one tool has updated. If you are lucky, you can take updated version as is, but in any case you can see what the potential problem parts are. For my own projects I do this specifically with the autoupdate from autoconf version that is minimum requirement for the project in question. That way autoupdate leaves my configure.ac still compatible with oldest autoconf version I mean to support. But if getting and using autoupdate version other than one in your system already is beyond you, any version gives you hints what to update.

And if you are author of package I'm not fixing for automake-1.13, here's the top 2 things you should check, and fix, from your configure.ac:
- AM_CONFIG_HEADER -> AC_CONFIG_HEADERS (note last 'S') - This is the most common problem by far
- AM_PROG_CC_STDC -> AC_PROG_CC - So far in every package it has been enough to remove AM_PROG_CC_STDC as AC_PROG_CC has already been there


Update 07-Jan-13 18:15 UTC: Stefano Lattarini points out that automake NEWS gives nice list of future incompatibilities for you to check and about new PLANS directory in source tree.

Comments

V mask

December 2014

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28293031   
Powered by LiveJournal.com