Configuration files (was: Standard compatibility)_(re)

Mon, 7 Apr 1997 19:09:22 +0200 (MET DST)

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]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)