Re: [9fans] ugrading edition 2 graphics to edition 3

["Douglas A. Gwyn" <gwyn@arl.army.mil>]

Matt wrote:
> Take out one file and one bit of script down the list suddenly falls apart
> because it was relying on an include higher up etc.

I'm not sure what you mean, but my guess is that you're saying
that an #include was removed from a source file after all references
to symbols documented as being defined by that header were no
longer referenced in that source file.

> I'm sure this must be true of a big C project too.

Not necessarily.  The last really big C project I was involved in
(MUVES) had everything arranged as "packages", each with its API
defined by a single header, e.g. "Mm.h" for everything in the
Memory-management package.  (All symbols in Mm.h begin with "Mm"
in order to avoid collision with any other package.)  It happened
that the Mm package needed to use some facilities from the Dq
(Doubly-linked queue) package and vice versa.  I forget whether
the "Dq.h" header needed to #include "Mm.h" and/or vice versa,
but if they had, there would be no problem (due to idempotency
locks in each header).  The key to the problem I think you were
mentioning is that *any* user of anything named Dq... was required
to #include "Dq.h" and similarly for any user of Mm...  Removing
the API for a package that became unused through edits to a source
file would have no effect on the remaining package headers.

Just as with the Plan 9 header discipline, if you don't follow
the discipline consistently, it can cause problems.  The rules
we used for the MUVES source were very easy to remember and follow,
and they never caused us any problems.  (Well, there was one
related problem, but it wasn't the fault of the header rules as
such.  MUVES used "unit testing" in its build procedure, to
validate each package's object modules before putting them into
the project library.  The unit testing linked the package test
program with the under-test package modules and the library.  When
first installing on a new platform, Dq and Mm each needed the
other package to have been already put into the library before
the test could be linked.  We devised a simple kludge to work
around this mutual dependency problem.)

Note: I haven't been arguing that the Plan 9 header discipline
is wrong, but rather that not all experiences with headers
including other headers have been negative.  Like many things
in life, nested inclusion itself is not a problem, but rather
how it is *used*.