On 21:41 29/05/04, Waldek Hebisch wrote:
[quotes from my previous message snipped]
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.
The --[pre|ap]pend... options would be very much appreciated, although I wouldn't use it much, if at all. I'm rooting for the .*dir.* stuff. :)
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.
It's not so much the loosing of EP compatibility that bothers me; it's the fact that I'm limiting that module to whatever path I tell the compiler to look for it. This isn't much of a hassle if only one or two components uses a module imported with `in ...', but it becomes a maintenance nightmare when a bunch of them have to import modules this way.
If you want total flexibility then clearly you want to have a "catalog" giving correspondence interface <--> file(s). However, what I propose
Yes, that would seem like a good (if not the best) way of implementing the feature I've suggested.
fetches needed parts for compilation. Anyway, more complicated interface <--> module <--> storage dependencies are better moved to a separate tool.
You might have just given me an idea for what I could work on in the future, although by `future' I mean `fuuuuuture'. ;b
(What does AFAIKS mean? I've Googled for it, but the only acronym I
s/K/C/
Ahh. I thought that might be it. :D
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).
As does, if you'll pardon my saying so, GPC's `in ...' extension to imported modules--and that's also what I said in my original message, hence the convoluted feature request.