This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: compile server design document
Michael Matz wrote:
I tell you: because setting up NFS servers would be another thing to do.
This really is a hurdle. ... With teambuilder and distcc this changed.
Simply install/run a daemon, and be done with it.
So why not write a user-space daemon on the user side that can
ship header files as the compilation daemon requests it? This
could be builtin to the process that ships off compilation
requests to the compilation farm. Or use ftp or a trivial
user-mode http server?
Anyway, if you say, that using preprocessed files is increasing network
load, the same happens for NFS/AFS based systems. There is no big
difference if the content for the preprocessed contents comes in directly
as preprocessed file, or from header files over NFS, at least not in the
direction you indicate.
If you ship preprocessed files you need to copy the header
file contents for *each* file you compile. If you use a
remote compile server it can (and will) cache the contents
of the header files between compilation requests. It seems
much more efficient to me. Also, you don't have to complicate
the compile server logic, except that you need to be able to
request a file over the network. That's a simple localized
change.
I tried to use all three approaches (NFS+pmake, distcc and teambuilder)
with KDE. pmake never really worked that well, distcc/teambuilder just
worked. So, while in theory totally equivalent solutions, in practice
there's a huge difference. compile servers not using preprocessed files
are practically unusable ;)
The conclusion does not follow.
--
--Per Bothner
per at bothner dot com http://www.bothner.com/per/