Re: autconf, configure & purify...

2008-10-23 Thread Ralf Wildenhues
Hello Antony, * Boggis, Antony wrote on Fri, Oct 24, 2008 at 01:47:43AM CEST: > After much googling and no answers (and least, none I can understand) > I am resorting to querying the wisdom of this list (and excuse me if > cc'ing is frowned upon). Yeah, it's usually nicer to choose one list only;

Re: autconf, configure & purify...

2008-10-23 Thread Ben Pfaff
Eric Blake <[EMAIL PROTECTED]> writes: > According to Ben Pfaff on 10/23/2008 10:06 PM: >>> AC_ARG_ENABLE([purify], >>> [AS_HELP_STRING([--enable-purify], [build with Purify [default=no]]), >> >> The Autoconf manual explicitly recommends underquoting >> AS_HELP_STRING (though not its arguments)

Re: autconf, configure & purify...

2008-10-23 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ben Pfaff on 10/23/2008 10:06 PM: >> AC_ARG_ENABLE([purify], >> [AS_HELP_STRING([--enable-purify], [build with Purify [default=no]]), > > The Autoconf manual explicitly recommends underquoting > AS_HELP_STRING (though not its arguments)

Re: autconf, configure & purify...

2008-10-23 Thread Ben Pfaff
Eric Blake <[EMAIL PROTECTED]> writes: > According to Boggis, Antony on 10/23/2008 5:47 PM: >> AS_HELP_STRING(--enable-purify,build with Purify [[default=no]]), > > This is underquoted. You need to get in the habit of properly quoting > your arguments: > > AC_ARG_ENABLE([purify], > [AS_HELP_STR

Re: use of AC_TRY_EVAL broken

2008-10-23 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 10/23/2008 5:09 PM: > There is a need for autoconf macros to compile and execute programs that > they have created with AC_LANG_CONFTEST > 1) without having to build up the compile or link command by itself, > 2) with l

Re: autconf, configure & purify...

2008-10-23 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Boggis, Antony on 10/23/2008 5:47 PM: > I have a global script that does the following (in this order): > > aclocal (aclocal (GNU automake) 1.7.3) > autoheader (autoheader (GNU Autoconf) 2.57) > automake -a

autconf, configure & purify...

2008-10-23 Thread Boggis, Antony
After much googling and no answers (and least, none I can understand) I am resorting to querying the wisdom of this list (and excuse me if cc'ing is frowned upon). We have a build environment that as it is, works pretty well. I have a global script that does the following (in this order): aclo

Re: use of AC_TRY_EVAL broken

2008-10-23 Thread Bruno Haible
Eric Blake wrote: > I'm thinking of removing AC_TRY_EVAL from the > next version of autoconf because of its security risks. There is a need for autoconf macros to compile and execute programs that they have created with AC_LANG_CONFTEST 1) without having to build up the compile or link command b

Re: config.status --recheck

2008-10-23 Thread Ralf Wildenhues
Hi Peter, * Peter Johansson wrote on Thu, Oct 23, 2008 at 04:57:35PM CEST: > Ralf Wildenhues wrote: >> * Eric Blake wrote on Thu, Oct 23, 2008 at 05:09:19AM CEST: >> >>> I also recall that Ralf Wildenhues checked in a fix that lets newer >>> automake insert additional .PHONY designations to .m4

Re: use of AC_TRY_EVAL broken

2008-10-23 Thread Paolo Bonzini
Eric Blake wrote: > The following gnulib files use an undocumented autoconf macro AC_TRY_EVAL, > which is buggy because it does not prevent against shell glob expansion > and could end up invoking arbitrary commands according to the contents of > the current directory. We need to switch these over

Re: config.status --recheck

2008-10-23 Thread Peter Johansson
Hi Ralf and Eric, Ralf Wildenhues wrote: * Eric Blake wrote on Thu, Oct 23, 2008 at 05:09:19AM CEST: I also recall that Ralf Wildenhues checked in a fix that lets newer automake insert additional .PHONY designations to .m4 files, so that make coupled with autoreconf can proceed after a renam

use of AC_TRY_EVAL broken

2008-10-23 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following gnulib files use an undocumented autoconf macro AC_TRY_EVAL, which is buggy because it does not prevent against shell glob expansion and could end up invoking arbitrary commands according to the contents of the current directory. We need