On Mar 6, 2016, at 9:07 AM, Paul Isaacs paul@redpineinstruments.org 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 gpaeper@empirenet.com