compile server design document

[Per Bothner]

Timothy J. Wood wrote:
> -  s/becomes we may allow/because.../

Fixed in the master.

> - The proposal doesn't explicitly say anything about threads, but you
>   could have each connection to the socket fork a thread.  Are you
>   planning on having this be threaded

NO.  That would require a more radical re-write of Gcc.  Gcc just
keeps too much state in global variables.  Plus you have to deal with
locking etc.

> or having dual processor machines just start two servers?

I think that makes more sense.

> - This design would let you get rid of all the PFE/PCH code for
>   persisting compiler state, assuming you want to dedicate VM
>   space to keeping a server alive.  But, do you think it would be
>   worth the effort to keep the 'persist the compiler state' code
>   around so that a server could be kick started.

My gut feeling is no.  But at a later point it might be worth
an experiment.
> 
>   As an example, each IDE project might have its own
>   persistent server database stored in the build directory with the
>   .o files for that workspace.  Thus, if I go through 15 different
>   IDE project while doing a large build, I might save some time.

Perhaps for release 2.0 of the compile server ...
> 
>   This disallows cross-project sharing but would mean that you
>   could have a large number of projects 'active' w/o having a
>   absolutely huge VM sucking server running.
> 
>   Basically, I'm just wondering if you have any data on this one
>   way or the other.

No.

> - Caching... what are your ideas on long lived servers?  This is
>   especially relevant if you don't have per- IDE project servers
>   (since one server could get handed thousands of files and grow
>   without bound)

Well, right now it is a per-directory server.  Per IDE-project
may be a future refinement.
> 
> - 'initially' and 'init' seem less than ideal for the naming scheme.
>   More descriptive, shorter and more unique names are possible:
>   'init'/'reset' or 'startup'/'perfile', for example

'startup'/'init' perhaps?

> - The 'depends-on-set' functionality seems like it would be very
>    useful in higher levels than the preprocessor (forgive me if it
>    misunderstood it... :)   Consider the case:
> 
>     foo.h:
> 
>         ... many other decls ...
>         extern void foo(float x);
>         ... some more decls ...
> 
>     foo.c:
>         void foo(float x) {...}
> 
>     bar.c:
>         void bar(float x) { foo(x); }
> 
>   If each decl was a 'fragment' then changing the type of the argument
>   to 'foo' would cause only foo.c and bar.c to be recompiled (instead of
>   all the files that include foo.h).

There are interesting things you can do.  For example, an IDE could
tell the compile server to only re-compile a single function.

The initial focus of the compile server is avoiding redundant heade
file compilation, but there are lots of things one could do beyond that.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/