lkml.org 
[lkml]   [2009]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/8] x86: remove dupilcated #include

* Sam Ravnborg <sam@ravnborg.org> wrote:

> > >
> > > I assume you are aware that when you minimize the # of include
> > > file in the various .c files, then you implicitly add dependency
> > > on the includes the individual .h files have.
> >
> > Yes. Look at the commit -tip that does the above change (also
> > attached below):
> >
> > a2bcd47: x86/mm: further cleanups of fault.c's include file section
> >
> > that commit uncovered a masked-until-then dependency bug in one of
> > the x86 include files.
>
> We have plenty of header files that needs other header files to be
> included in order to build.
>
> I tried to do a simple build check with a i386 defconfig.
> It revealed that the appended list of header files did not build.
>
> What I did was to create a simple:
>
> module.h.c file containing:
> #include <linux/module.h>
>
> And then I used kbuild to build the file,
> adding "obj-y += module.h.o" to Kbuild.
>
> I did so for all header files in include/linux/
> and result was that 172 header files failed to build.
>
> Some of these was expected since they are not supposed to be
> included direct. But the rest should build have
> build with no errors?
>
> I can automate the above included some way to say which header files
> we should NOT build.
> But eliminating the includes that are not needed is a bigger challenge
> and also the biggest win :-(
> Is it worthwhile to make the header files buildable alone?

I think it is definitely worthwile, for a couple of reasons:

- a data type definition that does not even build if included in a
.c file is broken, almost by definition. If it happens to build
in its current include file environment that's just a hidden bug,
nothing more.

- having such a check would simplify header dependency hell removal
efforts _immensely_. I could remove a suspect looking #include
line from a header and build with your check - that would be a
pretty good mechanism to drive header file simplification
efforts. (Human review goes only so far and it has failed to
reach its goal in the past 15 years, as it only addressed the
most obvious excesses.)

If we are too broken right now then maybe make it only available to
someone explicitly interested in it, via make
CONFIG_DEBUG_HEADER_DEPENDENCIES=y or so?

Ingo


\
 
 \ /
  Last update: 2009-04-09 06:35    [W:0.051 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site