Please integrate build framework into the compiler

[Christopher Wright]

Kristian Kilpi wrote:
> On Sun, 22 Mar 2009 14:14:39 +0200, Christopher Wright 
> <dhasenan at gmail.com> wrote:
> 
>> Kristian Kilpi wrote:
>>> #includes/imports are redundant information: the source code of 
>>> course describes what's used in it. So, the compiler could be aware 
>>> of the whole project (and the libraries used) instead of one file at 
>>> the time.
>>
>> That's not sufficient. I'm using SDL right now; if I type 'Surface 
>> s;', should that import sdl.surface or cairo.Surface? How is the 
>> compiler to tell? How should the compiler find out where to look for 
>> classes named Surface? Should it scan everything under 
>> /usr/local/include/d/? That's going to be pointlessly expensive.
> 
> Such things should of course be told to the compiler somehow. By using 
> the project configuration, or by other means. (It's only a matter of 
> definition.)
> 
> For example, if my project contains the Surface class, then 'Surface s;' 
> should of course refer to it. If some library (used by the project) also 
> has the Surface class, then one should use some other way to refer it 
> (e.g. sdl.Surface).

Then I want to deal with a library type with the same name as my builtin 
type.

You can come up with a convention that does the right thing 90% of the 
time, but produces strange errors on occasion.

> But my point was that the compilers today do not have knowledge about 
> the projects as a whole. That makes this kind of 'scanning' too 
> expensive (in the current compiler implementations). But if the 
> compilers were build differently that wouldn't have to be true.

If you want a system that accepts plugins, you will never have access to 
the entire project. If you are writing a library, you will never have 
access to the entire project. So a compiler has to address those needs, too.

> If I were to create/design a compiler (which I am not ;) ), it would be 
> something like this:
> 
> Every file is cached (why to read and parse files over and over again, 
> if not necessary). These cache files would contain all the information 
> (parse trees, interfaces, etc) needed during the compilation (of the 
> whole project). Also, they would contain the compilation results too 
> (i.e. assembly). So, these cache/database files would logically replace 
> the old object files.
> 
> That is, there would be database for the whole project. When something 
> gets changed, the compiler knows what effect it has and what's required 
> to do.

All this is helpful for developers. It's not helpful if you are merely 
compiling everything once, but then, the overhead would only be 
experienced on occasion.

> And finally, I would also change the format of libraries. A library 
> would be one file only. No more header/.di -files; one compact file 
> containing all the needed information (in a binary formated database 
> that can be read very quickly).

Why binary? If your program can operate efficiently with a textual 
representation, it's easier to test, easier to debug, and less 
susceptible to changes in internal structures.

Additionally, a database in a binary format will require special tools 
to examine. You can't just pop it open in a text editor to see what 
functions are defined.