This is the mail archive of the
mailing list for the GCC project.
Re: Do we have any plans to un-flatten our header files?
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 20 Apr 2015 12:23:33 -0400
- Subject: Re: Do we have any plans to un-flatten our header files?
- Authentication-results: sourceware.org; auth=none
- References: <20150420130207 dot GR2305 at virgil dot suse> <CAFiYyc0psChr_GSJ_9XTZhTrP2haSD7F5Vn5xMqHvztg0+8Rhg at mail dot gmail dot com>
On 04/20/2015 09:18 AM, Richard Biener wrote:
The problem with this simple approach (which was the original one) is
that you miss things like target macros and conditional compilation.
There was a long discussion about why that doesnt work in general, but
it boils down to constructs like
On Mon, Apr 20, 2015 at 3:02 PM, Martin Jambor <firstname.lastname@example.org> wrote:
because I really dislike the hassle our (almost) flattened header
files cause quite often, I have made a very simple experiment to find
out how the header files really depend on each other. Some results,
together with a dozen of short paragraphs of relevant text are here:
Short summary: I wrote a script removing an include at a time and
parsing errors and recording such discovered "dependencies." The page
has text-file reports showing what needs to be included before what,
in which files and because of which error messages. I have also
plotted a few graphs from these "dependencies." The pictures look
interesting, I am not sure if they are in any way useful, but have
a look and judge for yourself.
file.c compiles and executes perfectly fine without header.h... all you
get is suboptimal code which would be hellish to find later. The same
thing applies to header files which may depend on other header files...
this isnt a compilation-fail dependency Most of them will miss tm.h in
particular, but require some closer examination to see if they are
immune to this kind of thing.
Regardless of whether or not this experiment had any value. Do we
plan to do un-flattening of header files in the course of the next
release or two? The pain the flat header files is real and enduring
it for much longer or indefinitely seems unhealthy to me.
The goal was to end up with a few aggregating includes so you
just include sth like ssa-pass.h from a tree pass that works on
SSA form. Or gimple.h for anything that only needs to look at
The first step was the flattening to see what dependencies we have
(ok, it's not really good at that...) and to move stuff (mostly prototypes)
between files to reduce dependencies.
It's easy to create a ssa-pass.h file, but it's hard to determine
the minimum stuff that should be in there (no rtl.h for example).
For Andrews project (that tree stuff) the most important thing
is to not have tree(-core?).h leak into files that only use GIMPLE
(and thus the "valid" parts of tree).
I plan to spend some time and get it wrapped it during this stage
1... It flattened enough to be useful, and we ought to be able to
product better aggregators.