Headers including headers and precompilation

[Rob Landley]

On Friday 31 March 2006 1:09 pm, Robert P. J. Day wrote:
> On Fri, 31 Mar 2006, Rich Felker wrote:
> > On Fri, Mar 31, 2006 at 09:20:38AM -0800, Devin Bayer wrote:
> > > For what it's worth, I vote for the way I picked up and liked
> > > after programming with Cocoa for a while.  Have a single local
> > > header that includes all system includes used anywhere in the
> > > program, or at least in our case all SUSv3 and linux ones.  The
> > > main advantage is less maintenance.  But it also avoids the
> > > redundancy when local headers include a system header and so does
> > > the main.c file.
> >
> > IMO this is very bad practice. Not only does it hide what the real
> > dependencies are, but it also brings lots of unnecessary symbols and
> > definitions into the namespace of each file, increasing memory
> > requirements to compile, decreasing speed, and possibly causing
> > conflicts with names due to inclusion of unexpected headers.
>
> also, like i said before, this would cause all kinds of grief if that
> single local "catch-all" header file were to change in an unexpected
> way.  if every source file in your project never includes <stdarg.h>
> because it knows it will get it from "myfoo.h" and "myfoo.h" ever has
> to delete that include for some reason, you are *so* totally screwed.

If, by deleting an #include from myfoo.h, you break every file in the tree, 
then you don't delete it from myfoo.h unless you don't feel like fixing up 
every file in the tree.

When did this become hard to understand?

> also, it makes your source utterly non-portable.

I find it amusing that the MacOSX guy is defending the way busybox is 
currently doing it, and the _other_ side of the argument is calling it 
non-portable.

> you can't reuse that 
> source in another project unless you drag "myfoo.h" along with it.

The depth of my lack of caring is utter and profound.  It is awe inspiring.  
Entire invading armies could be blocked by this lack of caring.

The dependencies on libbb do tend to limit the ability to reuse busybox code 
outside of busybox, true.  The fact we're GPL instead of BSD limits the 
contexts in which our code can be re-used, too.  Neither is really 
significant.

> i have no objection to "libbb.h" or "busybox.h" including system
> header files.  clearly, that has to be done.  but for cleanliness, i
> think all of the source files should *pretend* that they have to look
> after their own header file inclusions.

So you don't think the source should match reality?

> rday
>
> p.s.  if you think about it this way, the header file "libbb.h" should
> naturally contain stuff related to the libbb stuff.  and as little
> else as possible.

Yeah, that's why we've got "busybox.h".  Which includes libbb.h for us. :)

Rob
-- 
Never bet against the cheap plastic solution.