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.
Regards,
Adriaan van Os