spurious change regenerating gdb/config.in?

spurious change regenerating gdb/config.in?

[Pedro Alves]

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?

Thanks,
Pedro Alves

Re: spurious change regenerating gdb/config.in?

[John Baldwin]

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.

-- 
John Baldwin

Re: spurious change regenerating gdb/config.in?

[Yao Qi]

On Wed, Oct 19, 2016 at 1:09 AM, Pedro Alves <palves@redhat.com> wrote:
> 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?

Yes, I see this.

-- 
Yao (齐尧)

Re: spurious change regenerating gdb/config.in?

[Pedro Alves]

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

Re: spurious change regenerating gdb/config.in?

[Maciej W. Rozycki]

On Wed, 19 Oct 2016, John Baldwin wrote:

> > 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.

 FWIW I can reproduce the phenomenon and I can see the ordering of these 
macros throughout this file being alphabetic by name (with the exception 
of some stuff inserted with AH_VERBATIM), so it looks to me like such 
regeneration is indeed due, though I'd consider the issue very minor.

  Maciej