Re: [9fans] Installing the updates

["rob pike" <rob@plan9.bell-labs.com>]

Perhaps I should explain better.

The only tenable argument in favor of allowing #include files to
include #include files is that a lot of software does that, so
permitting it makes software easy to port.  That is, I'm sure, why the
ANSI C committee accepted it: it's standard practice.

Nonetheless, it's a cop-out.  It's a terrible practice that leads to
n-squared inclusion of files, painful overwork by the C preprocessor,
and a bad name for the idea of #include files in the first place.

When designing the Plan 9 environment, we started with ANSI C for the
language.  Other than a couple of extensions to the language proper,
we took ANSI C at face value.  The library was also accepted pretty
much as is, with a few minor differences.  However, the C preprocessor
was unacceptable to us because a) it was very complex; b) it had lots
of new stuff designed by committee, a recipe for disaster; and c) most
of the new stuff encouraged conditional compilation and other horrors
we were trying to get away from.

Our idea was to build a portable system, one whose software could be
compiled without change - and that means without conditional
compilation, since you always have to change the #ifdefs when you
port; that is the very definition of config - as we changed
architectures.  Just architectures, not operating systems: we did not
expect Plan 9 programs to be compilable on Unix systems, but we did
expect a Plan 9 program that runs on a 386 to work on a SPARC, say,
without change, just by compiling it.

To meet that goal, we had to break with the ANSI include rules.

To import external code, we (well, Howard) built a fairly strict ANSI
C/POSIX environment that follows all the rules, including getting the
libraries and C preprocessors to have standard behavior.  If you want
to import code, that's the minimum effort path.

But if you want to build Plan 9 code, part of the environment is that
#include files don't #include each other.  That is just the way it
works, like not running X or using mk instead of make or setting
objtype=mips to build for the Mips.

In short, the argument that existing software #includes like that so
Plan 9 should is bogus, *because Plan 9 software does not*.

Plan 9 is a different environment, but it's different for a reason.
In the case of #include files, it's to make software easier to port
and simpler to maintain.  Within its own, admittedly smaller, world,
it succeeds.  Show me another system that builds all its software on
multiple architectures without #ifdefs or config.  Show me another
system where I can compile on a SPARC, link on a 386, and run on a
Mips.  Show me another system where I can update an application for
every architecture by typing the equivalent of
	mk installall
I'd love to hear of it!  But in this #ifdef, config-riddled world I
don't think it exists.

-rob