Due to AC_CACHE_CHECK, when APR_CHECK_TYPES_FMT_COMPATIBLE "fails" it
prints either a "yes" or "no".
So if the root APR_CHECK_TYPES_FMT_COMPATIBLE succeeds all is good,
which is the case for off_t on your system because long is first, so
we have a single "yes".
But if the root fails, the int64 case on your system because with int
first, the [ACTION-IF-FALSE] branch is taken *but* somehow the "no"
will be printed after the alternative, so here we are.
IOW, yes/no printing for nested APR_CHECK_TYPES_FMT_COMPATIBLE depends
entirely on how/when autoconf decides to print the result.
But my autotools foo are quite limited so I can't help here..
On Fri, Mar 22, 2019 at 6:12 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Doesn't make sense, that would be a noop (unless $apr_cvname is used in the
> true/false condition).
>
> Somewhere you nested something oddly. I worked around nesting with my last
> patch to this logic for the purpose of this specific macro, but in many other
> autoconf cases, true/false (as we used to do) don't evaluate as you might
> expect them to.
>
> On Fri, Mar 22, 2019 at 11:49 AM Yann Ylavic <ylavic....@gmail.com> wrote:
>>
>> On Fri, Mar 22, 2019 at 4:28 PM William A Rowe Jr <wr...@rowe-clan.net>
>> wrote:
>> > +checking whether int64_t and int use fmt %d... checking whether int64_t
>> > and long use fmt %ld... yes
>> > +no
>>
>> "yes" for %ld and "no" for %d, in stack order?
>>
>> Possibly it would print better with:
>>
>> Index: build/apr_common.m4
>> ===================================================================
>> --- build/apr_common.m4 (revision 1856042)
>> +++ build/apr_common.m4 (working copy)
>> @@ -995,9 +995,9 @@ APR_TRY_COMPILE_NO_WARNING([#include <sys/types.h>
>> ptr1 = &chk2;
>> *ptr1 = *ptr2 = 0;
>> printf("%$3 %$3", chk1, chk2);
>> -], [apr_cvname=yes
>> -$4], [apr_cvname=no
>> -$5])])
>> +], [$4
>> +apr_cvname=yes], [$5
>> +apr_cvname=no])])
>> ])
>>
>> dnl
>> --
