Frank Heckenbach wrote:
Concering GP versus `--automake': I think we need to fix main automake problems if we want GP to work well. Basically:
Just to clarify what we're talking about:
If you mean by "automake problems" problems with the current `--automake' implementation, I can't see why we need to fix them in order to make GP work well, as GP is there to replace automake.
Main automake problems to me are difficulties handling indirect recompilation needs. -- That's obvious from the way of doing things: Automake only has a local view, so the best it can do is try to rescue things in the last minute, i.e. recompiling other modules when reading their GPI files was already started. Add indirect requirements and cyclic dependencies to it, and you get all the problems we have with automake. Whereas GP (just like make) has a global view and can do things in the right order from the beginning.
- to have separate GPI file for implementation (so that interface
GPI stays consistent during compilation)
This would enable a `-j' option to compile the implementation of A while another process compiles a B that uses A. IMHO, that would be a minor optimization, otherwise I can't see it as a big problem.
- compile iterface and implementation separately (even if in the same
file)
Now referring to your 1% above ... ;-) I think this adds to compilation time (e.g., by having to load all imported GPIs twice), and I'd guess it would be a little more than 1%. Therefore I'd prefer (and that's what GP does) to do so only when needed, i.e. with cyclic imports, and not in the normal case.
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.
Regards,
Adriaan van Os