bug#13378: [PATCH] compile: use 'compile' script when -c -o is used with losing compilers

2013-01-11 Thread Stefano Lattarini
[Summarizing the relevant points of the past discussion, somewhat] Eric Blake wrote: But with m4, you can arrange for AM_INIT_AUTOMAKE to redefine AC_PROG_CC so that it hooks in a call to AM_PROG_CC_C_O immediately after its current definition, and thus still preserve desired ordering while

bug#13378: [PATCH] compile: use 'compile' script when -c -o is used with losing compilers

2013-01-11 Thread Eric Blake
On 01/11/2013 09:30 AM, Stefano Lattarini wrote: Subject: [PATCH] compile: avoid AC_PROG_CC messy rewrite Instead, only touch up AC_PROG_CC to distribute the 'compile' script and to rewrite $CC if a losing compiler is detected. We can do so because Autoconf 2.70 (which we now requires) has

bug#13378: [PATCH] compile: use 'compile' script when -c -o is used with losing compilers

2013-01-11 Thread Eric Blake
On 01/10/2013 06:33 AM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50 @acindex AC_PROG_CC_C_O -This is like @code{AC_PROG_CC_C_O}, but it generates its results in -the manner required by Automake. You must use this instead of

bug#13378: [PATCH] compile: use 'compile' script when -c -o is used with losing compilers

2013-01-11 Thread Stefano Lattarini
On 01/11/2013 06:56 PM, Eric Blake wrote: On 01/11/2013 09:30 AM, Stefano Lattarini wrote: Subject: [PATCH] compile: avoid AC_PROG_CC messy rewrite Instead, only touch up AC_PROG_CC to distribute the 'compile' script and to rewrite $CC if a losing compiler is detected. We can do so because

bug#13378: Backward-compatibility in the autotools (was: Re: [PATCH] compile: use 'compile' script when -c -o is used with losing compilers)

2013-01-11 Thread Stefano Lattarini
On 01/11/2013 07:19 PM, Eric Blake wrote: On 01/10/2013 06:33 AM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50 @acindex AC_PROG_CC_C_O -This is like @code{AC_PROG_CC_C_O}, but it generates its results in -the manner required by Automake. You

bug#13378: [PATCH] compile: use 'compile' script when -c -o is used with losing compilers

2013-01-11 Thread Stefano Lattarini
On 01/11/2013 07:19 PM, Eric Blake wrote: On 01/10/2013 06:33 AM, Stefano Lattarini wrote: Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50 @acindex AC_PROG_CC_C_O -This is like @code{AC_PROG_CC_C_O}, but it generates its results in -the manner required by Automake. You

bug#13351: [IMPORTANT] Dropping support for split '.info' files in mainline Automake

2013-01-11 Thread Paolo Bonzini
Il 03/01/2013 21:53, Stefano Lattarini ha scritto: Severity: wishlist [This is posted also to the automake and texinfo lists to ensure a wider audience. Discussion should continue exclusively on the bug-automake list, to avoid a cross-posting flood] Automake-generated have for a long

Re: perl ithreads support: why hardcode at configure time ?

2013-01-11 Thread Stefano Lattarini
On 01/11/2013 06:11 PM, Mike Frysinger wrote: On Friday 11 January 2013 04:08:26 Stefano Lattarini wrote: On 01/11/2013 05:07 AM, Mike Frysinger wrote: i can't imagine this is a big runtime penalty, so why does configure check for the perl's thread settings and then hardcode that in the

[PATCH] use runtime (not configure time) detection of perl threads

2013-01-11 Thread Mike Frysinger
I can't imagine the runtime checks being a big runtime penalty, so there shouldn't be a need to do the checks at configure check and hardcode the result in the generated automake. With the current system, it means if you change your perl config (build perl w/threads, build automake, build perl

Re: perl ithreads support: why hardcode at configure time ?

2013-01-11 Thread Stefano Lattarini
[+cc automake-patches, since patches should be discussed there] On 01/11/2013 05:07 AM, Mike Frysinger wrote: i can't imagine this is a big runtime penalty, so why does configure check for the perl's thread settings and then hardcode that in the generated automake ? I don't know, I wasn't

Re: How to auto probe a directory

2013-01-11 Thread David Yu
Hi Stefano: Thank you very much,I have realized my idea according your suggestion, The patch will be merged by skyeye(www.skyeye.org). i have configure.in include auto-probe.m4, I will probe all sub-directory and fill AC_CONFIG_FILES([Makefile]) into auto-probe.m4 after I create a device

Re: [Help-smalltalk] [PATCH] build: drop useless AC_SUBST of 'INCLUDES'

2013-01-11 Thread Paolo Bonzini
Il 11/01/2013 11:28, Stefano Lattarini ha scritto: * snprintfv/configure.ac: Here. Not only that substitution was useless, but it was causing runtime warnings with Automake 1.13, and, since support for $(INCLUDES) is bound to disappear in Automake 1.14 (in favour of $(AM_CPPFLAGS)), it will

Re: perl ithreads support: why hardcode at configure time ?

2013-01-11 Thread Mike Frysinger
On Friday 11 January 2013 04:08:26 Stefano Lattarini wrote: On 01/11/2013 05:07 AM, Mike Frysinger wrote: i can't imagine this is a big runtime penalty, so why does configure check for the perl's thread settings and then hardcode that in the generated automake ? I don't know, I wasn't

Re: perl ithreads support: why hardcode at configure time ?

2013-01-11 Thread Stefano Lattarini
On 01/11/2013 06:11 PM, Mike Frysinger wrote: On Friday 11 January 2013 04:08:26 Stefano Lattarini wrote: On 01/11/2013 05:07 AM, Mike Frysinger wrote: i can't imagine this is a big runtime penalty, so why does configure check for the perl's thread settings and then hardcode that in the

Re: perl ithreads support: why hardcode at configure time ?

2013-01-11 Thread Mike Frysinger
On Friday 11 January 2013 12:21:24 Stefano Lattarini wrote: On 01/11/2013 06:11 PM, Mike Frysinger wrote: On Friday 11 January 2013 04:08:26 Stefano Lattarini wrote: On 01/11/2013 05:07 AM, Mike Frysinger wrote: i can't imagine this is a big runtime penalty, so why does configure check