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
>
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
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
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 wil
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
devic
[+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'
