On Wed, 2015-07-22 at 20:50 -0400, Andrew MacLeod wrote:

(snip)

> I then ran it through an ordering tool, (which I will eventually put in 
> contrib).  This tool looks at include files, and puts them in a 
> "standard" order, and removes duplicates that have already been 
> included.. even if it is indirectly via another file.  ie, it will 
> remove obstack.h from the list if bitmap.h has been included for instance.
> removing duplicates was a very delicate balancing act when trying to 
> aggregate them with other includes,
> ie
> #include "option.h"
> <...>
> #include "target.h"
> 
> Since target.h includes tm.h (which includes options.h). we don't need 
> to include options.h  BUt there may be header files between the two that 
> require something in options.h, so target.h needs to be moved up to the 
> options.h location.   There are often secondary effects which affect 
> other files, and it turned out to be a frustrating juggling act.  So I 
> wrote the tool to take care of it. The standard "grouping" order of 
> includes turns out to look like :
>    "system.h",
>    "coretypes.h",
>    "backend.h",
>    "target.h",
>    "rtl.h",
>    "tree.h",
>    "fortran/gfortran.h",
>    "c-family/c-common.h",
>    "c/c-tree.h",
>    "cp/cp-tree.h",
>    "gimple.h",
>    "df.h",
>    "tm_p.h",
>    "gimple-iterators.h",
>    "ssa.h",
>    "expmed.h",
>    "optabs.h",
>    "recog.h",
>    "gimple-streamer.h"
> 
> This order resolves any issues.  The tool also looks at all the files 
> included by these and avoids including them a second time. Note that it 
> only puts header files into this order which are in the source file. so 
> if backend.h isnt in the file, and  function.h is, function.h will occur 
> where backend.h would be.   Any headers included by backend.h will occur 
> in that relative position, and in the order they are included by backend,.h
> 
> I will eventually put all these tools into a directory in contrib. It 
> simple enough to run it this ordering on any source file.

(snip)

If I'm understanding things right, we will have a standardized include
file ordering.

Can this ordering be documented somewhere in the source tree please?
(and be maintained)  I have a number of local (git) feature branches
that I'm hacking on, and every time I merge changes from master into one
of my branches, I seem to spend some time having to figure out which
include files I need.  I tend to just copy and paste #includes until it
compiles again, so having the order be documented would be helpful.

Hope this is constructive
Dave

Reply via email to