autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] AC_INIT: properly quote package name containing m4 macro


From: Eric Blake
Subject: Re: [PATCH] AC_INIT: properly quote package name containing m4 macro
Date: Thu, 17 Mar 2011 10:57:48 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

On 03/17/2011 10:32 AM, Ralf Corsepius wrote:
>>> m4_define([pkg_name], [foo])
>>> AC_INIT([pkg_name], [1.0])
>>>
>>> and that would result in AC_SUBST of PACKAGE_NAME=foo
>>>
>>> With this patch, it results in PACKAGE_NAME=pkg_name.
>>>
>>> [CUT]
>>>
>>> I don't see too much harm in making this change,
> 
> I do - If I understand this correctly, you are breaking a common trick
> being used by "big packages". Mine are amongst those and IIRC and so are
> others.

Please point me to an existing configure.ac that is relying on this
trick - I'd love to see a counterexample file in real life, to a) tell
you whether it would break (and not just you assume that it would), and
b) decide how easy it would be to change that package, or how many such
packages exist that depend on macro expansion.

And remember, autoconf itself uses:

AC_INIT([GNU Autoconf],
        m4_esyscmd([build-aux/git-version-gen .tarball-version]),
        address@hidden)

but note that autoconf intentionally expanded m4_esyscmd _prior_ to
calling AC_INIT, so AC_INIT only sees something like 2.68.58-f3c18. Note
that f3c18 in that version string is a valid macro name (but autoconf
does not declare a macro by that name), so it should not matter whether
the name is expanded or not for autoconf's usage of AC_INIT.

The problem at hand is that you _can't_ have it both ways (expanded vs.
unexpanded), but current autoconf 2.68 is trying to do it in both ways
(within a configure file, the _AS_DETECT_BETTER_SHELL snippet is
unexpanded, while the --help output is expanded).

We have an existing use case that argues for unexpanded (automake's
desire to write tests for dummy packages that use arbitrary names that
happen to match m4 builtins that aren't in the m4_ reserved namespace).
 Seeing existing use cases that argue for expanded, as well as a
comparison of which camp is larger, will definitely sway which way this
patch series goes (we may end up instead changing
_AS_DETECT_BETTER_SHELL to expand, and to tell automake to fix their
testsuite to avoid the issue of naming a package with an m4 builtin).

Either way, the current documentation for AC_INIT that talks about the
use of m4 macros to compute the literal arguments to AC_INIT needs to be
beefed up to provide an example; but should the example show
AC_INIT(macro) [because autoconf won't do any expansion after the fact,
per this patch] or AC_INIT([macro]) [because autoconf expands in place,
per the alternate patch, and package names like changequote are a huge
risk] as the preferred style?

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]