This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [cs branch] how to start compile server?


Per Bothner <per@bothner.com> writes:

> We haven't documented how to start the compile server, partly
> because we're trying figure out the right way to do it!

I don't know much about the project, so my apologies when I repeat
thoughts that people have already had.

The general notion of running a server is a well-understood one and
there is a lot of existing code to do it.  Recreating the code in gcc
itself seems mildly pointless.  Projects like tcpserver, xinetd, and
tcpwrapper exist to handle being a server.

I think that gcc should provide a very vanilla interface which can be
used by those tools.  That is, instead of worrying about how to run
gcc as a server, provide the simplest possible interface, and let
other programs handle all other details.

I think the simplest possible interface is this: cc1 reads commands
from standard input and reports results on standard output.  Nothing
else.  To run it as described in your paper, use a separate program
which binds a local socket and invokes cc1 with that socket on stdin
and stdout.

This gives maximal flexibility, by moving all the networking issues
outside of cc1 proper.  With the addition of protocol commands to ship
entire files, and a clear and simple definition of the output
protocol, it makes remote compiler serving possible.

Similarly, on the client side, I don't see any particular reason to
use gcc at all.  Instead, define a simple protocol--you've already
done this--and write separate programs to generate that protocol.  For
example, instead of `gcc -server', just use `gcc-server'.  That
separate program can then grow to take whatever options will be needed
to locate the server--using a URI naturally suggests itself.

It's possible that gcc-server will need to do some command line
parsing beyond simple stuff.  This may require turning the gcc.c
option handling into a library; I don't know.

In general, though, I think it's desirable to keep the networking code
out of gcc proper, and I think it can be done without loss of
efficiency.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]