Hi,
The schema of the cyclic dependencies I face is:
. Module A implementation section imports Module B . Module B implementation section imports Module A and Module C . Module C implementation section imports Module A and Module C
Please note the dependencies are in the implementation sections, not in the interfaces. Although for each module the interface section is in a separate file included in the appropriate implementation file (i.e. A.pas includes A.h but no other file), I think this is not the cause of the problem.
With this, gp says: cyclic interface dependency A.pas -> B.pas -> C.pas and it stops.
Hope this schema will help clarify the situation.
Regards
Pascal pascal@accovia.com
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Frank Heckenbach Envoyé : November 11, 2005 09:03 À : gpc@gnu.de Objet : Re: RE : compiling with gp (was
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
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8