FAQs about gecc

Why might a central controller help?

There are good arguments against a central controller to distribute the compile jobs. But there are also scenarios where a central component might help, imagine this:

• scenario one (S1): A reference machine where all the correct software (includes and libs) is installed. A team of developers build their revisions of a certain software. This is normal CVS business. This team of developers has often many equal sources files, because they currently edit only a small part. This should result in identically object files. Obviously compile time could be saved here with object code caching. Further this team has a certain amount of machines that may offer compile time from time to time. At some times (hours or days) they are completely used for somthing else, but from time to time they have cpu time to offer. These machines don't have all the good headers and libs installed, but the correct compiler. Here is potential to speed up compile jobs through distribution.
• scenario two (S2):You have a number of developers, that sit and compile on their own machine, compile a common project, thus share many equal source files. They could save compile time by sharing the object files. They could also speed up compilation if every developer could use many or all machines for his compile jobs. If the developers agree that they all benefit from this setup with shorter compile times it may (or may not) be acceptable to offer compile time on the own machine. It may be easier to accept if the developer has influence on when and how much cpu time is offered for foreign compile jobs (no time, if something time critical runs on the local machine, all time if the machine is idle for longer times).
• scenario three (S3):A slow machine (old hardware, throttled laptop) has the correct headers and libs installed, and want to compile a larger project (linux kernel, mozilla, ...) on this machine. If you compile it only one time you could not benefit from an object cache. If you could distribute the compile jobs, there would be a massive speed up. It might even be faster to compile only remote and nothing on the local but slow machine.

A central component may take care of a varying set of compile node. My idea is, that the compile nodes register themself at a central controller. This way the central job dispatcher sees what machines a currently available. I see no easy and clean way how this could be achieved without a central component.

Please note that a central component is often seen a SPOF (single point of failure). First of all, the failure of a central component doesn't have to result in a hangup of the complete system. If the client in a client/server setup is able to detect and recover from a server failure, then there would only be a penalty in time, not in reliability. The gecc architecture tries to take care of this.

A central component is not always a complication in itself. You may think of gecc as a C++ wrapper of the caching and distribution functionality. The fact that it is living in the same process space is no contradiction of the "one tool, one job" paradigma. Tests could be done in the granularity you like. Compiled binaries are one choice, C++ classes are another.