According to Frank Heckenbach:

So, if it get this right, one needs a way to pass data (in this case, strings) back from a child process to the parent process. I don't know very much about the available means of process communication, but isn't there any (portable) way to do so? Perhaps a temp file, or can it be done easier?

I am already doing this (in a portable way) for the AutoMake mechanism. There is an "internal" option `--amtmpfile=cc123456.gpc' which passes the name of a file containing the names of the `.o' files to be linked to the `gpc' driver program.

If every option (except those like $R,$I,$S,$Q(?) that would be the same like BP's) would be at least 2 letters, this would avoid name clashes.

Sounds reasonable. However I like the (*$W-*) ... (*$W+*) option as a quick way to disable/enable warnings locally. (Sometimes one may want to ignore a certain warning.) To have only (*$no-warnings*) ... (*$warnings*) would be a little drawback ...

At least I will make GPC warn about incompatible compiler switches when invoked with `--borland-pascal'. (It already does with `--pedantic.)

BTW: The first input file name sounds a bit strange to me. Rather, it should be the main program, I think. But it's probably not so easy to implement.

That's the reason. This is handled by the `gcc' driver program which does not read the source. But we might be able to solve this with the `--amtmpfile' mechanism ...

I don't know how field widths are handled, but I would suppose (and I think that's how BP does it) that the compiler would pass the given field width, or if omitted, the (current) default field width to the write routine.

They are handled differently in gpc-970401, but I just wanted to change GPC to use the method above.

[...]

Anyway, this was only an example, compiler options in the source and local options would be a plus anyway.

I agree. I will look at this.

(* I should set up a list of things I wanted to look at. A *long* list. ;*)

I'm not sure what this has got to do with it. Anyway, I think the biggest problem would be to collect all the options into one record (which might be quite hard if they're scattered among many modules now). Then, pushing and popping would reduce to storing/restoring this record to/from a (LIFO) stack.

Please look at `toplev.c', `gpc-options.h', and `gpc-decl.c' to get an overview.

Greetings,

Peter

Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]