On 2009-04-27, at 12:19, Tom Tromey wrote:
>
> This sounds like it has a lot of overlap with the incremental compiler
> project I was working on.  I think you could probably rearrange things
> to use the compile server infrastructure from the branch without
> trouble.
> 
> There are some differences in invocation.  I designed the incremental
> compiler so that no changes to user Makefiles would be needed; I don't
> know whether that is a consideration with Ada.

The idea is that gnatmake determines the total set of files to be
recompiled and then makes a single call to gcc with all those files.
The gain with that scheme is that the compiler proper can assume
the compilation of those files to be "atomic" in the sense that the
trees are guaranteed to be consistent within one compile job.
(Does the compile server also work this way?)

One other big plus with Ada is the lack of a preprocessor - no headaches
with different #define and #ifdef settings among files of a compile job.

> I think the compile server infrastructure is in decent shape, though I
> haven't worked on it in a while, so it is a bit hard to remember
> exactly.  The difficult bit is converting a front end to be
> server-ready; but from your note it sounds like you have already done
> that.
> 
> Oliver> It's not totally functioning yet:
> Oliver> 1) invocation of "as" (assembler) is only done for the first file
> 
> This is solved on the branch.  There, the server starts the assembler
> from compile_file.

That sounds interesting. I'll take a look.

> 
> Oliver> 2) gcc is passing too many switches to the compiler, for example
> Oliver> "-o" (output file) should be suppressed when in multi-source mode.
> 
> With the compile server you don't have to worry about this kind of
> thing.  I changed the options processing code to be re-initializable;
> each compiler job in the server runs with its own set of options.

Hmm. I'll have to look at that.

> Oliver> * toplev.c:
> Oliver> 1) Had to make realloc_for_line_map() global because when repeatedly
> Oliver> calling linemap_init(), the member "reallocator" is NULL and I
> Oliver> couldn't find a way of setting it to the proper value again.
> 
> I suggest a new public function in toplev.c that creates a line table.
> I did something similar to this on the incremental branch; except
> there I did not have to make it public, since server re-initialization
> is done in toplev.c.
> 
> I am curious how you handle locations on shared bits of the AST.
> I needed some disturbing hacks to make this work well for C.

I'm not sure what you mean; could you explain?

Oliver


Reply via email to