From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4.
Date: Sun, 2 Jan 2011 10:47:30 +0100 [thread overview]
Message-ID: <20110102094730.GA10365@gmx.de> (raw)
In-Reply-To: <20110102075953.GB8937@burratino>
* Jonathan Nieder wrote on Sun, Jan 02, 2011 at 08:59:53AM CET:
> Ralf Wildenhues wrote:
>
> > The patch should not cause any semantic changes in the generated
> > configure script.
>
> This part belongs in the commit message too, imho (though no need to
> resend just for that, of course).
Yeah, you're right.
> > - AC_LINK_IFELSE(AC_LANG_PROGRAM([], []), [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
> > + AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [git_cv_ld_dashr=yes], [git_cv_ld_dashr=no])
>
> Could you say a few words about the effect of this? Mostly because
> it would be useful to people down the line tempted to make the same
> mistake again.
Allow me to quote autoconf-2.68/NEWS:
** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
AC_RUN_IFELSE now warn if the first argument failed to use
AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file
contents. A new macro AC_LANG_DEFINES_PROVIDED exists if you have
a compelling reason why you cannot use AC_LANG_SOURCE but must
avoid the warning.
The underlying reason for this change is that AC_LANG_{SOURCE,PROGRAM}
take care to actually supply the previously computed set of #defines
(and include the standard headers if so desired), for preprocessed
languages like C and C++. In the above case, AC_LANG_PROGRAM is already
used, but not sufficiently m4-quoted, so that the autoconf warning will
be triggered bogusly.
The general rule for m4 quotation is: one set of quotes for each macro
argument, e.g.:
MACRO1([arg with MACRO2([arg], [arg])], [arg], ...)
and for innermost arguments which need to undergo no m4 expansion at all
a double set of quotes should be used, e.g.:
AC_LANG_SOURCE([[int s[42]; /* Program sources containing brackets. */]])
Only for some special macros that need to be expanded before recursion
no quoting should be used.
These and more rules are described in detail in 'info Autoconf
"Programming in M4"'. The rules can often be relaxed when the macro
arguments contain no active characters like comma, brackets or other
macro invocations themselves, but IMVHO it is easier getting used to
just quote things normally.
> > @@ -500,7 +494,7 @@ for l in $lib_order; do
> > old_LIBS="$LIBS"
> > LIBS="$LIBS $l"
> > AC_MSG_CHECKING([for iconv in $l])
> > - AC_LINK_IFELSE(ICONVTEST_SRC,
> > + AC_LINK_IFELSE([ICONVTEST_SRC],
>
> I'm curious about this one, too.
Likewise this is just underquotation leading to false positive.
> > @@ -931,18 +915,16 @@ AC_SUBST(NO_INITGROUPS)
> > #
> > # Define PTHREAD_LIBS to the linker flag used for Pthread support.
> > AC_DEFUN([PTHREADTEST_SRC], [
> > +AC_LANG_PROGRAM([[
> > #include <pthread.h>
> > -
> > -int main(void)
> > -{
> > +]], [[
> > pthread_mutex_t test_mutex;
>
> By the way, what problem is the warning about AC_LANG_PROGRAM meant to
> prevent? (Just curious. A five-minute google search didn't reveal
> anything obvious.)
See above.
I would be happy to update the patch in a way that makes it more
helpful, but most of the above is fairly general Autoconf rules,
so I'm not sure what you need (being blinded by looking at this
stuff too often).
Cheers,
Ralf
next prev parent reply other threads:[~2011-01-02 9:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-02 6:00 [PATCH] Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4 Ralf Wildenhues
2011-01-02 7:59 ` Jonathan Nieder
2011-01-02 9:47 ` Ralf Wildenhues [this message]
2011-01-02 10:00 ` Jonathan Nieder
2011-01-02 10:24 ` Ralf Wildenhues
2011-02-01 19:39 ` Ralf Wildenhues
2011-02-12 23:35 ` [PATCH resend] configure: use AC_LANG_PROGRAM consistently Jonathan Nieder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110102094730.GA10365@gmx.de \
--to=ralf.wildenhues@gmx.de \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.