[cfe-dev] final distributed clang patch

Eli Friedman eli.friedman at gmail.com
Mon Jul 7 10:24:41 PDT 2008


On Mon, Jul 7, 2008 at 9:13 AM, Peter Neumark <peter.neumark at gmail.com> wrote:
> Hi!
> Here is the final patch for clang to support network distributed
> compilation. (clang.patch file)
> There is also the server part attached. (the tar.gz file)

Okay... I'm not going to try and review the new code, just the
modifications to existing code.

> There 3 new files added to Driver directory:
> PrintPreprocessedOutputBuffer.cpp what is a modification of
> PrintPreprocessedOutput.cpp to support print text to a std::ostream.

No good; that's a large chunk of code which you're duplicating.  Would
a callback-based API be a significant performance hit?  Otherwise, can
you refactor the code to avoid duplication?

> Other new files: NetSession.h and NetSession.cpp which handles and contains
> all networking code (portable thin networking code).

Have you considered separating out the new code into a new directory?
I don't think it's a good idea to be mixing this stuff together; it'll
make reading the code in the Driver/ directory even more confusing
than it is now.

And actually, it might be a good idea to shift around some of the
existing consumers so that they can be used by outside projects more
easily.  A lot of the code currently in Driver/, like
PrintPreprocessedOutput, the rewriters, and the diagnostic printer, is
non-trivial.  Anyone have any thoughts on making a "lib/Consumers" or
a "lib/ConsumerUtils" directory to make this easier?  I know this is
something we've been putting off for a while, but it's gotten to the
point where it really needs to be done.

> There are some files changed, mostly to support saving its output to a
> std::stream. I've used that way to pass clang ASTConsumers data to an other
> computer via network.

I think we want to try and make the APIs of the included ASTConsumers
as general as possible.  To that end, it might be better to use some
sort of callback-based system, rather than having to force everything
to use iostream, or having to duplicate code to allow multiple IO
systems.

(I'm sorry about dragging your work into this architectural
discussion, Peter; I don't mean this as a comment on the quality of
your work.  That said, making the changes to existing code as clean as
possible is important, so this needs to be discussed.)

-Eli



More information about the cfe-dev mailing list