Re: [RFC] Sort #includes in gdb

[Tom Tromey <tom at tromey dot com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

>> I did not push this to the buildbot, as I believe it is too large for
>> that as well.

Pedro> ISTR that you could point the bot at some branch instead of a patch?

I don't know but I will ask Sergio when he's back.

Pedro> Yeah, there's a likely chance that this will break some native builds -- there are
Pedro> some headers that are (or used to be) order dependent.  I remember a small number of
Pedro> patches over the years moving header include order particularly in the
Pedro> architecture-specific Linux native files, around asm/foo.h, sys/foo.h, headers to
Pedro> fix the build in some particular kernel/libc version.  ISTR <asm/ptrace.h>
Pedro> as a particular trouble maker, but I could well be misremembering that one.
Pedro> I wish I could point at actual code / comments or commits, but I'm not
Pedro> finding much.  :-/

One thing worth noting is that the rewriting script is not very
sophisticated: it understands #include and #if (to a limited extent) but
it does not actually handle comments.

So, something like:

   #include <z.h>
   /* whatever */
   #include <a.h>

... will not result in any reordering.

This is somewhat lame, and I didn't check to see how many files this
leaves un-re-written yet; but on the other hand it provides a simple out
when ordering is needed.

Pedro> BTW, skimming the patch I noticed that the script didn't move
Pedro> this conditional include (HAVE_GETAUXVAL):

I fixed this.

Pedro> What do you think of having separate stanzas for C and C++ system includes?

I implemented this.

Pedro> A minor one: personally, I think I would prefer that all files from the
Pedro> same directory were sorted together.  I.e., instead of:

I implemented this as well.

Pedro> No firm opinion on comments vs no comments.

For now at least, I'm sticking with "no comments" because the lack of
comment-handling in the script means that adding comments makes the
script non-idempotent.  But, idempotency is a good quality to have,
because it means the script can be re-run at any time to fix any
"regressions" that have crept in.

Tom