[fpc-devel] extending fpc for integration
nc-gaertnma at netcologne.de
Wed Sep 29 23:46:25 CEST 2010
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
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.
More information about the fpc-devel