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). _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
