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

Mon, 7 Apr 1997 14:44:07 +0200

Peter Gerwinski wrote:

> > Does this also include the "-o ..." option? In this case, this "problem"
> > would also be solved by putting "{$o destname}" into the main program.
>
> That's problematic because the `-o' option is handled by the `gpc' driver
> program, not by the `gpc-cpp' preprocessor or the `gpc1' compiler which
> read the source.

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?

> > BTW: Are compiler options case sensitive? Otherwise there would be a possible
> > confusion with BP's "{$O filename}" for overlays.
>
> GPC's compiler options are not intended to be compatible to Borland
> Pascal's ones (except perhaps the most "basic" ones like $R, $I, $S
> which are compatible between UCSD and Borland).  These options are
> too system-specific; especially the "overlay" option makes no sense
> for GPC.

I didn't expect them to be compatible. Of course, that wouldn't make much
sense. But it might be better to avoid name clashes, so that ported BP
programs woudln't accidentally acces gpc options (e.g. a BP program foo that
declares an overlay {$O bar} should not be compiled to bar with gpc
(if {$O ...} would be implemented).

> But an `o' option (output file name) would crash with `O'
> (optimization), so these options should be replaced by long names,
> e.g. (*$output-file-name *) and (*$optimize *).

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.

> Here I agree.  BTW, EMX derives the name of the output file name from
> that of the first input file name.

Fine for EMX users...

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.

> > In such a way that they can be changed at any point in the source, like in
> > this (extreme and not very sensible) example:
> >  write({$field-widths=0,0,0}a,{$field-widths}b)
>
> This requires additional work due to the method how field widths are
> handled by the run time system.  It would be easier to make the default
> field widths variables accessible to your program, e.g. if you write
>
>     Var
>       DefaultIntegerWidth: asmname 'default_int_width' Integer;
>       DefaultRealWidth: asmname 'default_real_width' Integer;
>       DefaultBooleanWidth: asmname 'default_bool_width' Integer;
>
> Then you can save their values in local variables and restore them
> later ...

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.
>From this, I would think that default fields widths don't need to be runtime
variables, only internal variables of the compiler.

> (* Why don't you want to compile your whole program with -O2?

Because it's quite slow! Sorry to say that, but gpc is not so fast that I
can neglect this issue completely, being a poor 486 user...

> I would not release an unoptimized program as "production version".

No, but I'm writing programs mostly for my own use, that I have to compile
often (and therefore fast), and that have to run fast (but this always
concerns only quite small portions os the code). In 5-10 years, this will not
be an issue any more, but for now...

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

> > This example also shows that it can be desirable to "push" and "pop" options.
> > It would be better to write e.g. (tentative syntax):
> > [...]
> This would be relatively hard to implement.  I will not do that in
> the near future, but I wouldn't mind if somebody else would take care
> of that.  ;-)  But we must ensure that this will not break existing
> features of the preprocessor.  Also remember that (*$foo*) can also be
> written as #foo  ...

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.

> > I installed just the
> > necessary DJGPP stuff, do I need some more packages for symlinks? And do
> > symlinks also work for executables, or only for files accessed from within
> > DJGPP programs?
>
> Vice versa, they seem to work *only* for executables ... (?)

Oh, I see, you mean the stubs. I thought you were talking about "real"
symlinks, like e.g. symlinks with Linux' UMSDOS file system that don't
really fit to DOS.
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)