[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 w/o

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 >

Re: 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: >> >> > >> @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

Re: Backward-compatibility in the autotools

2013-01-11 Thread Eric Blake
[dropping the bug report; this is turning into a philosophical discussion more appropriate to just the mailing list, unrelated to the original bug at hand] On 01/11/2013 11:45 AM, Stefano Lattarini wrote: >> As a rule of thumb on when to remove a macro - I would personally like >> being able to w

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: >> >> > >> @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

Re: 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 s

Re: [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: > > > @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 > -@code{AC

Re: [FYI] {maint} tests: can fake a compiler not grasping "-c -o" -- globally in all tests

2013-01-11 Thread Eric Blake
On 01/11/2013 10:43 AM, Stefano Lattarini wrote: > The ability to easily do so will be quite important in upcoming changes > about C compilation handling and semantics of the 'subdir-objects' > option. Refer to the extensive discussion about automake bug#13378 for > more details:

Re: 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)

Re: [FYI] {maint} tests: can fake a compiler not grasping "-c -o" -- globally in all tests

2013-01-11 Thread Stefano Lattarini
On 01/11/2013 06:46 PM, Eric Blake wrote: > On 01/11/2013 10:43 AM, Stefano Lattarini wrote: >> The ability to easily do so will be quite important in upcoming changes >> about C compilation handling and semantics of the 'subdir-objects' >> option. Refer to the extensive discussion about automake

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 th

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 w

Re: 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 whil

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'