Hi all,
Just my two cents: Like Mr Van Os, I have myself the problem of cyclic dependencies in many programs I ported from SUN Pascal to GNU Pascal. There are hundreds of separate modules with cyclic dependencies up to 8th level.
For now, I use make to build the programs because of these dependencies. I have to call it two times to build the interfaces, because there are also cyclic dependencies in some interface sections that import others. Then I call it a third time to build the objects and link the programs. I know this is not the cleanest way but at least it works.
I tried gp and it did not worked because of these dependencies problem. But at least, it was useful because it helped me removing some of them. However, it would be a big job to remove them all and I have no time to do this for now.
If gp could manage the cyclic dependencies (I think it should continue to display them anyway) I would use it for sure. So I agree with Mr Van Os that it is a valuable feature in this case (porting programs to GNU Pascal).
Although I am not sure if I can completely build the programs with it since they link with many third party libraries and I have not found the way to do it in the gp documentation yet.
Regards
Pascal Viandier pascal@accovia.com
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Adriaan van Os Envoyé : November 11, 2005 02:04 À : gpc@gnu.de Objet : Re: compiling with gp (was
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