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

Sun, 6 Apr 1997 01:27:12 +0200 (MET DST)

According to Frank Heckenbach:
> 
> 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.

> 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.  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 *).

> I also suggest a compiler switch that will always choose the base filename as
> the destination filename, unless an explicit "-o ..." option is given.
> Then I could put this switch into a global configuration file/specs/whatever
> and wouldn't usually have to worry about "-o ..." options.

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

> 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 ...

> Perhaps also "--no-field-widths", equivalent to "--field-widths=0,0,0"?

Perhaps ... :-/

> The "-O" (optimization) switches could also be useful in the source, like:
> 
> [some non-time-critical code]
> 
> {$O2}
> 
> [very time-critical code]
> 
> {$O0}
> 
> [some non-time-critical code]

(* Why don't you want to compile your whole program with -O2?  I would
not release an unoptimized program as "production version".  (I have
been doing this long enough with BP now ...) *)

> This example also shows that it can be desirable to "push" and "pop" options.
> It would be better to write e.g. (tentative syntax):
> 
> [...]
>
> Then, after the "{$END}", the options would be like they were before the
> "{$BEGIN}", and if "-O2" was given from the command line, it would still
> be on in the last part of the code.

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  ...

> In fact, this is a missing feature of BP, and is often solved by workarounds
> like:
> 
> {$IFOPT R+}{$DEFINE R}{$ENDIF}{$R-}
> [...]
> {$IFDEF R}{$R+}{$ENDIF}
> 
> This works for a switch with only 2 possible values ({$R+} and {$R-}), but for
> siwtches like {$field-width=x,y,z}, it's not possible to do it like that, and
> it's not very nice anyway...
> So, pushing and popping options would really be a plus.

I agree, but see above.

> > In fact DJGPP supports symbolic links on DOS.
> 
> Really? I didn't find an "ln" command on my system.

Install GNU fileutils 3.13 or later.  See the DJGPP FAQ, chapter 22, for
more about symbolic links under DOS.

> 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 ... (?)

> Anyway, I don't think this would be a good solution for
> DOS systems,

Why not?  It works well for other DJGPP programs.

> but as many of you have shown, there are enough ways to supply
> default switches on any system, with or without an IDE...

Correct.  However we must carry those options too far:  even experienced
users will not like to deal with hundreds of command-line options ...

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)