[fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Marco van de Voort]

In our previous episode, Henry Vermaak said:
> > > I just add all the objects to a variable in a Makefile.
> > > 
> > > The result is that I have a 27000 line c library that compiles in *half*
> > > the time it takes to compile a 4000 line lazarus program because my c
> > > lib can be built with make -j 9.
> > 
> > I'm not exactly sure what this proves. The C situation is not equivalent to
> > the Pascal situation, the latter trying to make sure all (Pascal level
> > symbols) are there before the linker.
> 
> What I'm trying to say is that gcc is going 3 times faster on my quad
> core machine because of the build system, not because they've turned
> their compiler into a multi-threaded clusterfsck.

IMHO a threading clusterfsck is preferable to a forking clusterfck :-)

Yes. But is that incremental? It is fun to speed up a full build, but in
reality developers are more likely to do a partial one. Ever pressed F9
after a small change in Delphi? The app starts nearly immediately, if
the change wasn't too deep in the hierarchy of dependencies.

But compilation units in C have weaker(no) coherence than in (modular) Pascal, and C does
not have an auto build system. All dependencies are done manually.
(sometimes assisted with semi automated tools)

This means you need to manually specify in the build system which
compilation unit depends on which headers. And this is also why in C/C++
inline functions are in the header, so that this model is persistent, since
most builds are not full, but incremental.

To build (possibly incremental) an interweaved codebase means handling
complete control to make, and essentially means castrating FPC to the gcc
model of one process, one compilation unit (and killing all auto dependency
tracking and no recompile unless updated).

This also means that for every codebase dependencies must be maintained. 
There might be semi-automated tools for it, but it is always a manual
responsibility in the end.  This is more or less done for the RTL.  If it
fails however, the result is partial builds, and errors pascal people are
not used to.

Of course you can also try to identify isolated groups of uses that can
be build in parallel, and try to build those, with autobuild within
that group. This happens in the packages/ directory, where only the
dependency graph of whole dirs is maintained.

> assuming that the same can't be achieved with pascal, then (without
> making the compiler itself multi-threaded)?

Basically, there is a small piece of make in the compiler for incremental
building, and determining what sources need to be compiled (just handing
a mainmodule +dirs to the compiler will build it all).

This means the compiler can make decisions outside make's control, and also
does extra checks (to find a consistent state for the code that abides the
modular system before linking)

As shown above, you can work around that with makefile generators
(packages/) or hard work (rtl/). But  for dynamic codebases of closely knit
units like IDEs and compilers there really is no solution atm.

If you have an option to force the compiler to only compile one unit, you
could emulate the C model.  You could even improve on the C situation by
letting the compiler terminate on inconsistent incremental build state (to
signal the dependencies are fscked)

But even when in theory (which I btw don't even want to consider), you are
equivalent to C in this way, it basically means disabling the unit system,
and users must start to manual maintain dependencies, and learn to
interpretate cryptic errormessages if an incremental build goes haywire.

C users and developers are trained in this, and have their experience in
detangling the web of deps etc, have developed semi-automated helper tools
etc.

Inflicting this on the Pascal masses is unrealistic and undesirable.
Sticking to the manual build principles because the FPC devels can handle it
essentially means that nobody else will have parallel builds, or will resort
to a system of doing full builds only. (but that is throwing away the big
savings to gain small ones). Something that big C projects resort to anyway,
I'm told.

And FPC even only in a few critical points.

Manual maintenance is simply too painful (and atypical for modular languages and
its users).