From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200008011335.JAA17292@cse.psu.edu> Subject: Re: [9fans] Installing the updates From: "rob pike" Date: Tue, 1 Aug 2000 09:35:52 -0400 To: 9fans@cse.psu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: f082b1aa-eac8-11e9-9e20-41e7f4b1d025 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