Frank Heckenbach wrote:
Adriaan van Os wrote:
Compiling interface and implementation parts separately indeed adds the overhead of importing GPIs twice (unless, of course, the symbol tables are stored in shared memory and passed as a parameter to GPC). However, this applies to a full build. In actual practice, you often are working on one unit at a time (maybe making small changes to type definitions in earlier units). So, what you want is the fastest way to compile *that one* file. Compiling implementation parts of other units is at that moment just a waste of time.
Typically, while developing there will be many more compiiations of single units than full builds. For example, I am porting now a big application to GPC and it is progressing very nicely, but compile times are horrible. The scenario:
- compile a unit
- fix problems in the unit (mostly in the implementation part)
- recompile the same unit (takes up to 20 minutes, even without any
interface changes) 4. fix more problems, 5. goto 1
I guess there is a bug in GP (probably related to cyclic dependencies) that triggers (too many) recompilations, even when only the implementation part of a unit has changed (or maybe even when nothing has changed).
Anyway (since I have a lot of time available during compile runs) I volunteer:
- to find the GP dependency bug or bugs
- to add a switch to GP to compile only the interface parts of used
units, to speed up compiling a single unit.
I am now implementing for gp:
--compile-file Compile a file as fast as possible. Imported units that need recompilation are compiled --interface-only, which implies that successive linking will fail. Therefore, this option is useful during the development phase only. This option implies -c --check-file Check the syntax of a file as fast as possible. Imported units that need recompilation are compiled --interface-only. This option implies -c
It mostly works already (I will post a diff later). The time gain is dramatic.
IIUC, this is only necessary because of the bug you suppose in your previous mail (otherwise no other units would have to be recompiled if not changed)? So it might be a better use of time to concentrate on the acutal bug than on temporary work-arounds.
No, I consider this a valuable feature, although the impact may in general not be so dramatic as in my current project, porting an application to GPC with many cyclic dependencies (which I didn't write myself).
Did you already send a reproducible test case (if you can't or don't want to fix the problem in gp yourself)?
I will try to be useful and fix gp myself. Compile times are also spoiled by the quadratic operator search (http://www.gnu-pascal.de/crystal/gpc/en/mail10055.html) and that is something I cannot fix easily myself (at some points in the compilation I see the IDE's progress bar and line counter move line by line, often lines with calculations).
Regards,
Adriaan van Os