Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!aplcen!haven!rutgers!columbia!read.columbia.edu!
From: @read.columbia.edum) (f)
Newsgroups: comp.lang.c++
Subject: Re: A solution to the multiple inclusion problem
Keywords: #include c c++ inclusion
Message-ID: <6562@columbia.edu>
Date: 24 Oct 89 19:13:43 GMT
References: <14240@well.UUCP> <2082@plx.UUCP>
Sender: news@columbia.edu
Reply-To: kearns@cs.columbia.edu
Organization: Columbia University Department of Computer Science
Lines: 20

The best solution of all is to (conceptually) get rid of separate
compilation.  One might define a "project" file which is basically a
list of the .c, .lib, and .h files that make up a program.  The C compiler
would know about this project file; you no longer compile a file, you
compile a whole project.  

Conceptually, with a project structure, all the non-static function and
variable definitions are available to any file in the project.  No 
#include statements are needed.  The compiler can precompile definitions
etc... to implement separate compilation, but all of that is an implementation
detail.  For backwards compatibility one can define a "file interchange 
format" which mainly requires the compiler to generate a set of files
with the proper includes.  

Lightspeed C for the macintosh has a small part of this system.  You define
a project by listing the .c and .lib files; it scans the .c files for
the includes to automatically construct a makefile for you.  

-steve
(kearns@cs.columbia.edu)