Pascal Viandier wrote:
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.
To avoid misunderstandings: GP generally should be able to handle cyclic dependencies. I've used it compile a project with ~200 units, all interdependent (not written by me, obviously :-).
So we don't need to discuss whether to do that.
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.
Cyclic dependencies within interfaces are forbidden, both in Borland and Extended Pascal. (I.e., interface A uses interface B, and interface B uses interface A.) GP will also reject this, and there's really no sane way to do this, as you could easily construct circular definitions and contradictions this way.
What you can do is: Interface A uses interface B, and implementation B uses interface A. Then GP should, in this order, compile interface B, all of A, implementation B.
If that's what you need, then GP should work for you. There may be abug, perhaps the same one Adriaan found, and then, of course, I'd like to fix it, when I know what it is ...
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.
Libraries are easy. There are two ways, both work the same with GP as with automake, and the second one also with manual make:
- Put {$L} directives in the source (see e.g., the GMP and RegEx units that come with GPC).
- Add -l options on the command line.
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).
Perhaps I don't yet quite understand it. Provided GP makes no mistakes and imports are not recompiled unless necessary. So I suppose you mean the situation that you changed the implementation of an imported unit? But you don't want to compile (and therefore check for syntax errors) this other unit?
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).
I see. BTW, Waldek are you interested in the general solution of this issue (including overloaded routines)? I'm not too much ATM (there are many more urgent issues). If you aren't either, perhaps I could at least try some quick fix to ease this problem somewhat. -- Still using name-based search, with all its disadvantages, but perhaps storing a list of actually defined operators in the OPERATOR_DECL (this will also be a preparation for the real solution), and then for each operator retrieve the type names and compare them -- I suppose if we get rid of the ACONCAT and get_identifier in the loop this way, this might make things much faster.
Frank