Re: configure.in vs. configure.ac

[Eric Blake]

On 09/12/2012 03:57 PM, Karl Berry wrote:
>     [Autoconf is deprecating the name 'configure.in']
> 
>     rms> ... its configure.in file ...
> 
> See how prevalent the configure.in name is in people's minds, let alone
> software?  I hope you will reconsider your decision to "deprecate" it.

It has already been deprecated for more than 10 years (since autoconf
2.50 in 2001), and is costing active maintainer effort to support both
names.  These days, no one in their right mind uses anything older than
autoconf 2.59.  Furthermore, if you care enough about your project to
update to a newer version of autoconf, renaming configure.in to
configure.ac is probably not the only thing you will have to change if
your project has been that far behind the times.

https://www.gnu.org/software/autoconf/manual/autoconf.html#Writing-Autoconf-Input

> 
> I still see many software packages, GNU and especially non-GNU, which
> use configure.in.  What's the advantage to making extra work, even if
> trivial, for many of the autoconf-using developers in the world?  There
> must be something important or you wouldn't be doing it, but I can't
> imagine what it is.

With autoconf, the '*.in' suffix is typically used for files which
config.status will convert into the final file, after configure has run.
 Just as you tend to compile '*.c' files, where the suffix tells you the
tool to use, configure.ac is the preferred name because '*.ac' says that
the tool to use is autoconf, whereas '*.in' says that the tool to use is
configure.  But configure.in is NOT converted by config.status (rather,
by autoconf), as it makes no sense to produce 'configure' at the
conclusion of a 'configure' run, so the name 'configure.in' is misleading.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature