* Re: spurious change regenerating gdb/config.in?
2016-10-19 3:23 ` John Baldwin
@ 2016-10-19 13:09 ` Pedro Alves
2016-10-19 15:55 ` Maciej W. Rozycki
1 sibling, 0 replies; 5+ messages in thread
From: Pedro Alves @ 2016-10-19 13:09 UTC (permalink / raw)
To: John Baldwin, gdb-patches
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: spurious change regenerating gdb/config.in?
2016-10-19 3:23 ` John Baldwin
2016-10-19 13:09 ` Pedro Alves
@ 2016-10-19 15:55 ` Maciej W. Rozycki
1 sibling, 0 replies; 5+ messages in thread
From: Maciej W. Rozycki @ 2016-10-19 15:55 UTC (permalink / raw)
To: John Baldwin; +Cc: gdb-patches, Pedro Alves
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
^ permalink raw reply [flat|nested] 5+ messages in thread