Neil Santos wrote:
On 19:15 29/05/04, Waldek Hebisch wrote:
AFAIKS there are two remaining problems:
- There is no default way to find implementation so plain `--automake' (or `gp' (alias `cgp', alias `gpmake')) can not find them. IMHO we need to introduce a convention here. I propose to have `module.p' for interface and `module-imp.p' for implementation.
That is one of my main points in my original message.
With all due respect, I propose a different system: one wherein we could tell gpc (through maybe a command-line parameter) where it could search for the sections it needs. We could then name our interfaces and implementations the same, and just store them in different directories; maybe interface/ and implementation/ directories, or something similar.
We could then, maybe, have other parameters to fine-tune the search: something like --prepend-interface-name or --append-interface-name, and --prepend-implementation-name --append-implementation-name.
This hypothetical version of gpc could then be invoked this way:
gpc myprog.pas --automake--module-interface-dir="./interface/" --module-implementation-dir="./implementation/" --append-interface-name="-interface" --append-implementation-name="-implementation"
Our hypothetical gpc would go compile myprog.pas, and when it encounters an import statement (say `import somemodule'), it goes into ./interface/ and looks for a file named `somemodule-interface.pas' to get the interface section, then goes to ./implementation/ and looks for a file named `somemodule-implementation.pas' to get the implementation.
I do not like to split implementations and interfaces into different subdirectiories (at least for my programs). The `--append-...' options could of course work without the `...-dir..' options. However together we get rather have machinery, and still not very flexible.
Of course, employing such a system would have to be much more robust, considering modules don't have to be named the same as the file that contains them, and that modules can export items under a different name.
You can write:
import e1 in 'mod15m.pas';
to tell gpc that interface `e1' is contained in file 'mod15m.pas'. The drawback is that the "in 'mod15m.pas'" part is gpc extension, so you loose EP compatibility.
However, I believe that such a system would be much more flexible than requiring GPC users constrain themselves to having module implementations named `module-imp.pas'; no offense, Waldek. :)
If you want total flexibility then clearly you want to have a "catalog" giving correspondence interface <--> file(s). However, what I propose is very simple to implement and gives you one way to implement modular design. Also, having simple rule to get implementation file name from module name makes thing simpler for people.
On the other hand EP model fits well with database technology, so one can imagine a tool that stores sources in a database and at build time fetches needed parts for compilation. Anyway, more complicated interface <--> module <--> storage dependencies are better moved to a separate tool.
(What does AFAIKS mean? I've Googled for it, but the only acronym I can find for IKS (I'm assuming AFA means As Far As) is `Imperial Klingon Ship', `Interkantonale Kontrollstelle fur Heilmittel' (which I can't decipher further than `International Something for Something'), and `Tiksi', which is Russian (or so acronymfinder.com tells me))
s/K/C/
By the way, you wrote about `--include' option and the Chief suggested putting `{$incude ...}' directive in the interface. Both IMHO defeat the purpose of separate interface, as effectively interface and implementation are compiled jointly (only disk storage is separate).