[fpc-devel] extending fpc for integration

[Mattias Gaertner]

On Wed, 29 Sep 2010 22:50:47 +0200
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> Mattias Gaertner schrieb:
> 
> > I did some test with an integrated fpc (e.g. in an IDE) and sharing
> > redirecting the file access. For example FPC could use the files
> > of the IDE.
> 
> IMO most time can be saved by using the directory cache, instead of 
> building another one in the compiler.

I only tested reading/writing files. 
In a second step the functions for file existence, age
and size can be made overloadable. I doubt it will make fpc faster
under Linux, but I guess under Windows it could be noticeable in some
cases.
The compiler spends some time parsing the ppu files. Maybe this could
be cached, but as far as I can see this is not an easy task.

 
> > This would allow to compile without saving to disk, so the
> > compiler could be used for quick syntax checks and similar tasks.
> 
> That's an old idea, still viable but never implemented.
> 
> > Note: Under Linux the speed up is hardly measurable. But
> > maybe Windows can gain a bit.
> 
> There's another issue with the .ppu files, that are used by the compiler 
> to prevent excessive re-compilation of the same units. But recompilation 
> can be forced, with some minor patching.

I'm not sure what issue you mean.

 
> > I changed a few calls to Assign/Reset/Close to use the TCFileStream
> > (e.g. for the ppu reader) and added the possibility to define a custom
> > TCFileStream class. An IDE can then redirect the file access.
> 
> The scanner already has a configurable file interface, but AFAIR only by 
> global hooks, not on a per-file or per-application base (finput.pas: 
> tdosinputfile...). No real problems, so far :-)

What global hooks do you mean?

 
> But there exist other issues, e.g. the compiler currently can compile 
> only for a single target, that is incorporated at compile time. One 
> solution were a dummy target, that does not create any binary code in 
> the IDE compiler version. Or the compiler back-ends are moved into their 
> own classes, selectable at runtime. I've explored both approaches 
> already :-)

I agree that a single exe multi platform compiler would be nice, but it
is not necessary for my goal.
My goal is to reduce the overhead of invoking the compiler
many times a day for the same project.

Mattias