[cfe-dev] Compile Server?

Douglas Gregor dgregor at apple.com
Mon Jan 17 16:24:08 PST 2011


On Jan 17, 2011, at 4:02 PM, David Claughton wrote:

> On 17/01/11 18:15, Douglas Gregor wrote:
>> 
>> As Reid notes, C/C++ make caching of intermediate results really
>> tricky. However, you can perform some optimizations, e.g., detecting
>> common sequences of prefix headers and automatically generating
>> precompiled headers for them.
> 
> Yes, this is the sort of thing I had in mind, start with automatically
> creating a PCH file for all the headers in the first source file and
> check whether it can be used for the next.  There is, I think, a tiny
> bit of flexibility in that if the second source file only includes the
> first few headers (in the same order) than it should be OK to use the
> first part of the PCH.  I think that should cover quite a lot of common
> cases.

Right. If the compiler server knows what files it will be building, it can compute common prefixes and build PCH files for them. It could also cache stat() calls, coalesce file-opening operations, etc.

> Once that is in place, it might then be possible to try to go further.
> I've read the gcc-compile-server paper referenced in the original thread
> and I can see that navigating the dependencies problem is fraught with
> difficulties - however it might be possible to identify some limited
> cases where it might be safe to proceed and sort of nibble at the
> problem from the edges?  If nothing else I will probably learn a lot
> from trying, which is almost never a bad thing ;-)

I don't think that the dependencies problem can ever be nibbled away. The header-inclusion model is so fundamentally broken that it can only really be fixed by introducing some kind of real module system. That's not to say that the compile server is a bad idea---it isn't, and it could be very powerful---but I don't think it's worth going for a partial/limited solution to the dependencies problem.

>> I think one of the other goals of a compiler server is to support
>> interactive clients, such as an IDE. So, it's not that we have a list
>> of compile jobs provided in advance: we have requests coming in,
>> typically for some smallish set of files that are constantly
>> changing, and we need to return results quickly.
> 
> Hmm, interesting.  If the IDE were written in C++ it would probably be
> more efficient for it to call the libraries directly - but I can see the
> advantages for something like Eclipse.


There are other reasons to want a compile server. Perhaps the IDE is just vim, where people start and kill sessions constantly and could benefit from persistent state in the compile server. Or the build step that's invoked from the IDE is actually calling out to "make", so your compile server could optimize the in-editor queries alongside the build itself. Or you want to isolate your perfect, bug-free IDE from that crash-ridden Clang compiler :)

	- Doug



More information about the cfe-dev mailing list