Peter Gerwinski wrote:

...

• Commandline options to specify the directory(ies) a) to search for units/modules (source or compiled)

My current plan is to use the `-L' path/s for this purpose.

Yes, why not! (What I'd like best is if it (with "--automake") would look for a source file in the current directory and the "-L" path, and for a compiled module in the "-L" path and the b) path (see below), and if it finds both, compare the dates, regardless where it found them. I think that's how BP does it -- or even a little bit better... :-)

...

b) to put compiled modules (.o, .gpi, .gpm) c) to put compiled programs (executables).

\begin{sigh} Even more options! \end{sigh}

But those are more useful than average, I think... ;-)

I, personally, can't stand other files put between my sources, and for executables, there usually exists a separate directory, anyway...

What about extending (*$executable-file-name="foo"*) to accept a directory? Or else (*$executable-path-name="/foo"*) and (*$object-path-name="/bar"*)?

I don't agree. The *name* of the executable can be considered part of the program. The *path* where it will be stored will be system dependent, so the path, IMHO, does not belong into the source, but on the commandline (or into a (system or user or project specific) config file, of course).

...

• Passing the actual size for untyped (resp. void) parameters, so it can be access with sizeof.

This would spoil compatibility to other languages such as C.

What about:

var x:void -> like C var/const x -> like BP

So perhaps make "Procedure Foo ( Var x )" pass the size, and keep "Procedure Foo ( Var x: Void )" as it is (i.e. without passing the size)?

I was typing too soon before reading this... :-)

Or introduce another data type?

Only if necessary. (But I don't see why it would be, since there are already two types and two purposes -- if existing programs with "var x" do rely on C compatibility, those (few, probably) programs should be changed rather than the compiler...)

Okay; I have put it on my list.

Fine! :-)

And another one:

For procedural variables, BP uses "@ProcVar" to cast them into a pointer(!!!). gpc does not understand this, but the (more logical, IMHO) "Pointer(ProcVar)". Unfortunately, BP doesn't accept the latter, so AFAICS there's yet no way that works on both. :-( Since we can't change BP, we should make gpc recognize "@ProcVar", perhaps also only in "--borland-pascal".