Re: [Patch] libgcov.c re-factoring

[Jan Hubicka <hubicka at ucw dot cz>]

> On 12/22/2013 01:27 PM, Jan Hubicka wrote:
> >
> >I believe when the code was created by moving it from elsehwre, the copyright should say
> >original date of gcov-io.h.
> >>+
> >>+#include "tconfig.h"
> >>+#include "tsystem.h"
> >>+#include "coretypes.h"
> >>+#include "tm.h"
> >>+#include "libgcc_tm.h"
> >....
> >I would really like someone working on header restructuring to comment on
> >those.
> >I am not 100% sure what our best practices currently are in respect of
> >including headers within headers and specially after good amount of
> >defines like gcov-io.h gets included.
> >
> >
> Just back..
> 
> For the moment the goal with headers is to completely flatten them..

OK. Seems sensible.  I will push IPA/cgraph/symtab in this direction
next stage1.

> ie, we do not want to include header files from header files.  Once
> there is a sensible restructuring of things in place, we are likely
> to reintroduce them in a controlled and sensible manner.
> 
> So at the moment, I'd like to not include any additional .h files
> from within .h files...

The situation here is slightly more slipperly than in other cases, since we
have headers (gcov-io.h.h) that is shared across GCC coverage code and runtime
(libgcov) and stand alone tools (gcov-tool and gcov).

The header has several ifdefs that makes it to do the right thing in all 3 contexts
that are different.
The change in question is to pull out a lot of mess that is specific into runtime
to libgcov specific header file that includes gcov-io.h later in game.  In a way
I see this as an improvement, since runtime bits are localized to place where
rest of libgcov is (that is for some reason libgcc and not libgcov directory)
rather than hidding it in geenral purpose header.
I suppose it will also make easier to make libgcov portable to non-stdio based
environments, like in kernel, that is google's desire.

What would be preferred solution here?

Honza
> 
> Andrew
>