Re: spurious change regenerating gdb/config.in?

["Maciej W. Rozycki" <macro at imgtec dot com>]

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