First let me thank all that are involved in creating this Pascal compiler on linux. You are doing a great job!
It's mere exsistence and (hopefully:) its quality make it possible for me for the first time to undertake what has been a dream of me for so many years: porting this largish (over thousand prestine source files) 80's project.
It went from unix pascal to VAX/VMS Pascal to MetaWare Pascal back on a sun, and now finally to Extended Pascal with gpc.
I very much would like to stick to Extended Pascal as close as possible. But (un)fortunately iso10206 doesn't define all, so the first silly problem I have is that of naming the files.
What is generally thought of as the proper extension to use for files holding an Extended Pascal Interface Module, and what is the proper extension for files holding the corresponding Implementation Module. Both for the simple case where each module only has one interface exported.
And finally, do you deem it wise to use yet another extension to denote a file containig an Extended Pascal Program as opposed to a Module of some sort?
Carel Fellinger wrote:
What is generally thought of as the proper extension to use for files holding an Extended Pascal Interface Module, and what is the proper extension for files holding the corresponding Implementation Module. Both for the simple case where each module only has one interface exported.
GPC is rather liberal WRT file name extensions. It tries to accept "all known Pascal" extensions, currently .pas, .p, .pp and .dpr (in descdending order of preference, at least of mine ;-).
"Accept" in the meaning that it considers them as Pascal sources without special options (`-x Pascal') and that it searches for modules/units in such files. It makes no differences between EP modules, UCSD/BP units and programs in this regard.
More tricky is the question of the base name of modules. GPC allows you to put both interface and implementation in the same file. If this file is named like the interface, GPC will find it automatically by the `import' statement. Otherwise you can use the (non-standard I think) `in 'filename'' addition.
If you prefer to put them in two distinct files, I'm not sure (I haven't done this), but I guess you might have to specify at least on of the file names on the command-line (or in the Makefile) then.
And finally, do you deem it wise to use yet another extension to denote a file containig an Extended Pascal Program as opposed to a Module of some sort?
I don't do so myself, I call everything `.pas' (instead, I put my general-purpose units and my small programs in separate directories, ~/units and ~/progs, while my larger projects typically contain one program (easily recognizable by the name of the projects) and several project-specific units in one directory).
If you prefer, you can choose between the four accepted extensions as you see fit. Or do you have yet another one in mind? ;-)
Frank
On Thu, Mar 07, 2002 at 12:00:59AM +0100, Frank Heckenbach wrote:
Carel Fellinger wrote:
...
GPC is rather liberal WRT file name extensions. It tries to accept "all known Pascal" extensions, currently .pas, .p, .pp and .dpr (in descdending order of preference, at least of mine ;-).
Yep, read about that in the docs (by the way, the docs have improved a lot in release 20011222), but I was wondering if people were giving special meaning to some of those extension, like using `.pp' for interface files. Apparently not.
...
More tricky is the question of the base name of modules. GPC allows you to put both interface and implementation in the same file. If
I prefer two files. And prefer to compile them seperately. Does wonders to the recompilation time:) This project has two files, but used `pragma C-include' voodoo instead of proper separate compilation. I'll remedi that at some later time, to start I'll `import' other modules but `include' the module interface file in the module implementation file.
this file is named like the interface, GPC will find it automatically by the `import' statement. Otherwise you can use the (non-standard I think) `in 'filename'' addition.
If you prefer to put them in two distinct files, I'm not sure (I haven't done this), but I guess you might have to specify at least on of the file names on the command-line (or in the Makefile) then.
If I understand correctly, the import statement will read in the `.gpi' file and not look for the source of that module, right? So if I have files `module.interface', `module.implementation' and a program importing module named program.pas then compiling them as:
$ gpc -c --interface-only -x Pascal module.interface $ gpc -c --implementation-only -x Pascal module.implementation $ gpc program.pas module.o
should work. A little test suggests this works. Ofcourse things will get prolematic when the basename of the file doesn't match the module name. But I thought `.gpm' was used to solve that problem?
...
If you prefer, you can choose between the four accepted extensions as you see fit. Or do you have yet another one in mind? ;-)
The project I'm porting used `.pf' for interface modules. So I've to use the `-x Pascal' flag (took me some time to find it's an uppercase Pascal, in the docs I read first it was a lowercase p). Could as wel change the extension to something more telling, hence I asked.
Carel Fellinger wrote:
On Thu, Mar 07, 2002 at 12:00:59AM +0100, Frank Heckenbach wrote:
If you prefer to put them in two distinct files, I'm not sure (I haven't done this), but I guess you might have to specify at least on of the file names on the command-line (or in the Makefile) then.
If I understand correctly, the import statement will read in the `.gpi' file and not look for the source of that module, right?
With `--automake' it will also look for the source. Without I don't think so (but not sure, since I never do this myself).
should work. A little test suggests this works. Ofcourse things will get prolematic when the basename of the file doesn't match the module name. But I thought `.gpm' was used to solve that problem?
No, `gpm' is used to find the interfaces when compiling the implementation to import them automatically. But that's not completely right because declarations not exported in any interface are not visible in the implementation this way. So we'll change this (add another `gpi' file which contains everything from the interface module, and import this one when compiling the implementation, then I think `gpm' is not needed anymore).
If you prefer, you can choose between the four accepted extensions as you see fit. Or do you have yet another one in mind? ;-)
The project I'm porting used `.pf' for interface modules. So I've to use the `-x Pascal' flag (took me some time to find it's an uppercase Pascal, in the docs I read first it was a lowercase p). Could as wel change the extension to something more telling, hence I asked.
Well, if it's really useful (e.g., compatible to some other compiler), we could add `.pf' to the list of the recognized extensions. After all, it doesn't make a big difference if we have 4 or 5 of them. What do you think?
Frank
On Sat, Mar 23, 2002 at 04:03:21AM +0100, Frank Heckenbach wrote:
Carel Fellinger wrote:
...<usefull anwsers snipped>
The project I'm porting used `.pf' for interface modules. So I've to use the `-x Pascal' flag (took me some time to find it's an uppercase Pascal, in the docs I read first it was a lowercase p). Could as wel change the extension to something more telling, hence I asked.
Well, if it's really useful (e.g., compatible to some other compiler), we could add `.pf' to the list of the recognized extensions. After all, it doesn't make a big difference if we have 4 or 5 of them. What do you think?
I wasn't around when they decided to use this extension, it might be the case that MetaWare Pascal used it, but no I wouldn't suggest to add it.
On the other hand I would very much like to have *some* extension agreed upon to be used for interface-only source, say ".pi". That way it becomes possible to apply --automake to true separate compilation.
To me it seems elegant that when interface and implementation are split in separate files, their file names only differ in extension, and it would definitely help if a specific extension was allotted to interface sources and a different one to implementation sources.
The automake would then first try to locate a separate ".pi" interface file, compile it and import the "gpi", and later but prior to calling the linker it would try to compile the accompaniing ".p" or ".pas" implementation file. If that separate interface file isn't found, then the ".p" or ".pas" file is taken to contain both the interface as wel as the implementation and it is compiled just once at the moment it is needed in an import statement.
I don't think it's worth the trouble to distinguish between program, implementation-only or shared-interface-and-implementation files, as I don't see how this serves any purpose for the automake process.
Note: I don't know were the ".pp" extension stems from, if it's used like ".p" or ".pas" then it should be included in the above discussion were ever ".p'and ".pas" are mentioned. If its use is unspecified, then asfar as I'm concerned ".pp" is as good as any as `interface-only' extension (though ".pi" is nicer as it's closer to ".gpi").
-- groetjes, carel
Carel Fellinger wrote:
On the other hand I would very much like to have *some* extension agreed upon to be used for interface-only source, say ".pi". That way it becomes possible to apply --automake to true separate compilation.
To me it seems elegant that when interface and implementation are split in separate files, their file names only differ in extension, and it would definitely help if a specific extension was allotted to interface sources and a different one to implementation sources.
The automake would then first try to locate a separate ".pi" interface file, compile it and import the "gpi", and later but prior to calling the linker it would try to compile the accompaniing ".p" or ".pas" implementation file. If that separate interface file isn't found, then the ".p" or ".pas" file is taken to contain both the interface as wel as the implementation and it is compiled just once at the moment it is needed in an import statement.
I don't think it's worth the trouble to distinguish between program, implementation-only or shared-interface-and-implementation files, as I don't see how this serves any purpose for the automake process.
Oh, so you're not mainly talking about file names, but about the automake mechanism.
Well, as far as our plans go, automake will disappear in the future and be replaced by an external utility. This utility is currently under development, but for now it doesn't have much support for separate interface/implementation files, either. (And it will not really "need" it because it will use more intelligent mechanisms to decide when to recompile, i.e., even if interface and implementation are in the same file, but only the implementation was changed since the last recompilation, it won't recompile dependent files.)
So I suggest do postpone any such discussion until this change (which might not happen too soon, actually, since automake is currently working almost fine, so the priority is not too high, but I don't want to invest any more effort in automake since it's bound to disappear).
Frank
On Sun, Mar 24, 2002 at 01:15:39AM +0100, Frank Heckenbach wrote:
Carel Fellinger wrote:
On the other hand I would very much like to have *some* extension agreed upon to be used for interface-only source, say ".pi". That way it becomes possible to apply --automake to true separate compilation.
...
Oh, so you're not mainly talking about file names, but about the automake mechanism.
Not only --automake, but any automake, e.g. I'm considering to use SCons:)
Well, as far as our plans go, automake will disappear in the future and be replaced by an external utility. This utility is currently under development, but for now it doesn't have much support for separate interface/implementation files, either. (And it will not really "need" it because it will use more intelligent mechanisms to decide when to recompile, i.e., even if interface and implementation are in the same file, but only the implementation was changed since the last recompilation, it won't recompile dependent files.)
Arrch, yet another make:) Did you have a look at SCons? It tries to do the same by calculating md5sums (IIRC), seems to work.
So I suggest do postpone any such discussion until this change (which might not happen too soon, actually, since automake is currently working almost fine, so the priority is not too high, but I don't want to invest any more effort in automake since it's bound to disappear).
I see, seems like the right thing to do. None the less it would be a good thing if the Extended Pascal or the gpc community would agree on the use of an extension for interface modules.
Carel Fellinger wrote:
Well, as far as our plans go, automake will disappear in the future and be replaced by an external utility. This utility is currently under development, but for now it doesn't have much support for separate interface/implementation files, either. (And it will not really "need" it because it will use more intelligent mechanisms to decide when to recompile, i.e., even if interface and implementation are in the same file, but only the implementation was changed since the last recompilation, it won't recompile dependent files.)
Arrch, yet another make:) Did you have a look at SCons?
Just a brief one now, hadn't heard of it before.
Well, one would have to add Pascal specific capabilities to it (e.g., understanding `uses' and `import'). Given that I have already done this in my program (gp), this seems the easier way to go. ;-)
Besides, it seems to be a little Python oriented:
: Configuration files are Python scripts--no new syntax to learn.
I can say the same thing about gp: Config files will be similar to Pascal (not full Pascal, but a limited subset of it) -- no new syntax to learn. :-)
It will be no full `make' replacement, it will just replace automake for Pascal files (and make the command-line invocation of gpc a little easier). For more complex build procedures, it will still be reasonable to call gp from within a makefile (or possibly SCons) that does the rest.
It tries to do the same by calculating md5sums (IIRC), seems to work.
Yes, I also use md5sums.
I see, seems like the right thing to do. None the less it would be a good thing if the Extended Pascal or the gpc community would agree on the use of an extension for interface modules.
Since I'm not part of this community (i.e., I don't use separate interface files), I abstain from this decision.
Frank
-
Carel Fellinger -
Frank Heckenbach