Bruno Haible wrote:
> Sorry for the delay.
>
>> I've reworked those patches accordingly,
>> but didn't test on a MacOS X system.
>> Since your name is on them, I'll wait until
>> you acknowledge before pushing.
...
> Sure, fine with me. You can put yourself into the ChangeLog entry, of course.
> I
Hi Jim,
Sorry for the delay.
> I've reworked those patches accordingly,
> but didn't test on a MacOS X system.
> Since your name is on them, I'll wait until
> you acknowledge before pushing.
>
>
> From 6bfdd76f3f2e3b03be407dcfab7a231259d23d15 Mon Sep 17 00:00:00 2001
> From: Bruno Haible
> Dat
Jim Meyering wrote:
> Bruno Haible wrote:
> ...
>>> It looks to me like the change below is equivalent to yours,
>>
>> Ah, I see now what you mean. Fine with me.
...
Hi Bruno,
I've reworked those patches accordingly,
but didn't test on a MacOS X system.
Since your name is on them, I'll wait un
Peter O'Gorman wrote:
> > The configure test whether mktime works produces the result "yes" in 32-bit
> > mode and "no" in 64-bit mode. ...
>
> This is surprising, what is the reason for the 64 bit failure?
It is not surprising when you look at the function bigtime_test in
m4/mktime.m4.
Bruno
Bruno Haible wrote:
> Jim,
>
> The configure test whether mktime works produces the result "yes" in 32-bit
> mode and "no" in 64-bit mode. In universal builds, we cannot manage these
> different results (it would become a #ifdef mess). Therefore I propose to
> combine the results to "no". OK to co
Bruno Haible wrote:
...
>> It looks to me like the change below is equivalent to yours,
>
> Ah, I see now what you mean. Fine with me.
>
> I wouldn't have chosen this solution because it tears apart the
> determination of the ac_cv_func_working_mktime into two parts,
> one before the AC_CACHE_CHEC
Hi Jim,
> It looks to me like the change below is equivalent to yours,
Ah, I see now what you mean. Fine with me.
I wouldn't have chosen this solution because it tears apart the
determination of the ac_cv_func_working_mktime into two parts,
one before the AC_CACHE_CHECK and one inside it (making
Bruno Haible wrote:
>> That looks like it'd work fine
>
> It does work fine. I tested it :-)
>
>> but I'd like it even more if it were
>> to set the cache variable to "no" *before* the use of AC_CACHE_CHECK.
>> Then, this change would be more compact and would not affect the logical
>> structure (
Hi Jim,
> That looks like it'd work fine
It does work fine. I tested it :-)
> but I'd like it even more if it were
> to set the cache variable to "no" *before* the use of AC_CACHE_CHECK.
> Then, this change would be more compact and would not affect the logical
> structure (i.e. no need for the
Bruno Haible wrote:
> The configure test whether mktime works produces the result "yes" in 32-bit
> mode and "no" in 64-bit mode. In universal builds, we cannot manage these
> different results (it would become a #ifdef mess). Therefore I propose to
> combine the results to "no". OK to commit?
Hi
Jim,
The configure test whether mktime works produces the result "yes" in 32-bit
mode and "no" in 64-bit mode. In universal builds, we cannot manage these
different results (it would become a #ifdef mess). Therefore I propose to
combine the results to "no". OK to commit?
2008-12-25 Bruno Haible
11 matches
Mail list logo
