> Marco van de Voort wrote: > > > > immediately contribute to the size of a compiled module, only when they > > > are *used* in code modules. > > > > That goes for all routines. > > I'm not sure what you mean. A global procedure, exported in the > interface section of a unit, always must be be compiled.
> Only the linker can determine which procedures really are used in a > project, and which ones can be omitted. A specific procedure can be used > in one project, but can be unused in another project. Think of the > standard units like System... Yeah, but smartlinking/deadcodeelimination is a pretty standard feature. > > > In comparison with C/C++, "uses" summarizes the #include of header files > > > and the dependency checks of Make. > > > > The important difference (in TP/Delphi/FPC) is that preprocessor state > > doesn't follow USES statements. > > Do you mean that only one level of dependencies must be checked with > "uses", whereas even the indirectly #included files must be checked for > changes? You always have to do the #include. Always. Pre-compiled headers are possible, not trivial, since it requires a comparison of the entire preprocessor state to see if a header needs recompilation. > > That allows the compiler to auto-find the compilation order.. > > What's the importance of a compilation order? It is something that doesn't come cheap. > > The effect of units is that it is a lot safer (more guaranteed) and easier > > to implement that precompiled header files, and auto-building is also a lot > > easier (not requiring explicit manual compile order enforced) > > Again I don't understand what you mean (compile order???) :-( Not recompiling the headers each time saves a lot of time. > A C project doesn't require any compilation order, every module can be > compiled independently from other modules. Implementation: yes. Header: no. [snip] > Such a construct of course is illegal, because of infinite recursion. > The same construct would be perfectly accepatble with pointers: > > type > A = record a1: ^B; end; > B = record b1: ^A; end; Yes. But it doesn't even have to so complex. Simply two files having dependancies on eachother, without having cycles in types are most typical. > My idea for extended external declarations: IMHO it is not a problem that needs solving, specially not with extra syntax. > > IIRC TP could handle mild circular references and so can FPC. I don't know > > if this is still the case. > > Sounds interesting, do you have more information? No. It could also be that one of the other devels remember how it exactly went. I quickly tested, and it doesn't work now: -bash-2.05b$ fpc unit1 Free Pascal Compiler version 1.9.9 [2005/03/29] for i386 Copyright (c) 1993-2005 by Florian Klaempfl Target OS: FreeBSD/ELF for i386 Compiling unit1.pas Compiling unit2.pas unit2.pas(5,11) Fatal: Circular unit reference between unit2 and unit1 Error: /home/marcov/bin/ppc386 returned an error exitcode (normal if you did not specifiy a source file to be compiled) So if it worked at a certain point it was removed later. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel