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:
1. compile a unit 2. fix problems in the unit (mostly in the implementation part) 3. 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