Re: Importing

> On Mar 6, 2016, at 9:07 AM, Paul Isaacs <[email protected]> wrote:
> 
> Hello,
> 
> I noticed that imports done outside the interface-specification-part are not dependency checked by --automake. This creates problems for first time gnu pascal uses such as myself.

GPC’s —automake has problems so back in late 2005 Frank Heckenbach created a new dependency checking analyzer and auto-building driver progeam for GPC called ‘gp’.  You can find the source code for gp at <http://www.gnu-pascal.de/contrib/frank/gp-0.61.tar.bz2>.  (There is a README file in the tarball that give directions in using gp instead of gpc  —automake.) 

> 
> I started placing imports outside the interface-specification-part to avoid circular dependencies and it took a while to understand that --automake was no longer finding the import dependencies.

The gp driver program correctly separates interface-specification-part import dependencies from implementaion-part import dependencies.  In those cases where an implementation-part import creates a source code “whole” file circular dependency, gp correctly avoids “whole” file circular dependency problem by first having gpc do only an interface-specification-part compilation of the necessary source code files and (if successful) followed by gpc doing only an implementation-part compilation of the necessary source code files.

Note: In a few rare cases (which I haven’t been able to distill down to a good reproduceable error test case) gp might be slightly off of “what needs recompiling” in a partial recompilation after a source code change recompilation and you’ll get something like an “interface x needs recompiling” error when compiling a using/importing implementation-part.  If you encounter that sort of problem, the fix is just doing a clean/from scratch build of all your program’s source code.


> 
> I also assumed that the reason for the, rather awkward, multiple interface capability was to get around the module circular dependency problem. Ada resorted to the kludgy 'limited with' workaround.
> 
> Gnu pascal seems to have resorted to the import 'in' workaround. However, having filenames in the source code does not seem to me to be a good idea.

Actually, GPC’s import 'in’ workaround isn’t for solving circular dependency problems; rather, it is used to explicitly tell the compiler which source code file something can be found instead of using the default implicit mapping of unit/module “name” to filename “name”.p[.pas][etc] for specifying the file location.


> 
> Would "import modulename_interfacename" work?

Really doesn’t change the problem you’re trying to solve.  You’re still left with where in the heap of files do I find the “name” and the correct one at that of all the potential occurrences of “name” in the heap. 

A lot of different schemes for that problem have been tried over the years and all but a few end up having a filename explicitly or implicitly embedded in the mapping of “name” to its “found” location somewhere in the scheme.

Gale Paeper
[email protected]




_______________________________________________
Gpc mailing list
[email protected]
https://www.g-n-u.de/mailman/listinfo/gpc