On 01/06/2014 09:37 AM, Jan Hubicka wrote:
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?
Yeah, this isnt only a compiler header file, so what makes the most
sense may be different. The rationale for flattening the compiler
header files is to get a grasp on what is coming from where, regroup
things in a more logical manner, then possibly reintroduce a more
sensible include hierarchy.
If this is improving the locality of the runtime then I wouldnt worry
about it. we haven't gotten anywhere near that yet :-) I didnt
realize on first glance that it was a libgcc file. if we ever do get
that far, we can deal with it then :-) It isn't undoing anything we've
done so far.
Andrew
