Re: spurious change regenerating gdb/config.in?

[Pedro Alves <palves at redhat dot com>]

On 10/19/2016 04:08 AM, John Baldwin wrote:
> On Wednesday, October 19, 2016 01:09:53 AM Pedro Alves wrote:
>> If I run autoheader on the gdb/ dir, I see this spurious
>> change come out:
>>
>> diff --git c/gdb/config.in w/gdb/config.in
>> index c82a5b4..3790d10 100644
>> --- c/gdb/config.in
>> +++ w/gdb/config.in
>> @@ -453,12 +453,12 @@
>>  /* Define to 1 if your system has struct lwp. */
>>  #undef HAVE_STRUCT_LWP
>>  
>> -/* Define to 1 if `struct ptrace_lwpinfo' is a member of `pl_tdname'. */
>> -#undef HAVE_STRUCT_PTRACE_LWPINFO_PL_TDNAME
>> -
>>  /* Define to 1 if `struct ptrace_lwpinfo' is a member of `pl_syscall_code'. */
>>  #undef HAVE_STRUCT_PTRACE_LWPINFO_PL_SYSCALL_CODE
>>  
>> +/* Define to 1 if `struct ptrace_lwpinfo' is a member of `pl_tdname'. */
>> +#undef HAVE_STRUCT_PTRACE_LWPINFO_PL_TDNAME
>> +
>>  /* Define to 1 if your system has struct reg in <machine/reg.h>. */
>>  #undef HAVE_STRUCT_REG
>>
>>
>> This is with pristine FSF autoconf 2.64.  I suspect this is
>> just because the config.in in master was generated by some
>> other autoconf version.  To confirm, does anyone else
>> see this?
> 
> I don't see this, but feel free to fix.  It is likely my fault somehow as I
> added the associated check.  I had used a pristine FSF autoconf (built and
> installed to a custom prefix to avoid it using any other autoconf), so I'm
> not sure why it is different.

OK, thanks.  It's not a big deal.  Was just wondering whether
the issue was on my side.  Since Yao confirms, it doesn't look
like it.

If when you regen on your side, you still see it like you originally had
it, I wonder whether this is a sorting bug in autoheader or one of
the utilities it might spawn (perl, shell, etc.?) somewhere.  It seems
like the HAVE_FOO #undef/#define's in config.in are alphabetically
sorted.  If I regen, it's fixing the sort.  Seems like these macros
are the longest named ones in the file, that may be related.

Anyway, I'll push it in in a sec.

Thanks,
Pedro Alves