J. David Bryan wrote:
On 14 Nov 2002 at 9:49, Prof A Olowofoyeku (The Afric wrote:
Is anyone else interested in having environment variables for the GPC driver to cover things like "unit-path", etc.? [...] I might well patch the GPC driver for Mingw to do just that....
Actually, this was already possible (with a three-character patch to "lang-specs.h", if I recall the filename correctly) by setting the otherwise-empty "*gpc1" entry in the "specs" file. One could set, e.g.:
-funit-path=F:\Pascal\Units
or
-fobject-path=R:\Global\Objects
in the specs file and automatically add those paths to every GPC compilation (unless --no-unit-path was given for the GPC invocation). I have been using the specs file to include a unit path and also:
-fexecutable-file-name
...so that I don't get "a.exe" if I neglect to specify an output filename. And finally, I had added this (wrapped for clarity only):
%{!fclassic-pascal-level-0:%{!fclassic-pascal: %{!fextended-pascal:%{!fobject-pascal: %{!fborland-pascal:%{!fdelphi:%{!fpascal-sc: %{!fgnu-pascal:-fextended-pascal}}}}}}}}
...to have GPC default to Extended Pascal unless one of the other specifiers appeared on the command line.
Regrettably, though, it appears from the changelog that specs processing has been removed from GPC for this release.
The `gpc1' spec was removed, not specs processing in general. It's possible to add the options elsewhere, but this is (for the most part) not recommended.
(Besides, the setting as above doesn't really suffice -- there are other parts of the specs that depend on the dialect options, and which would have to be changed accordingly, to avoid surprises ...)
The specs are meant for the global defaults, not for per-user settings etc. The difference may be hard to understand to a Windows user, but please try. ;-) A global unit path might be alright, but not a local path for personal units etc. (I can't tell from your information which one you mean), and certainly not a dialect option.
Consider the case when you (or some other user, maybe someone who picks up your specs from the list or so) compiles a package downloaded from the net and gets mysterious errors because the package doesn't assume such local options.
Therefore, invoking `gpc' should exhibit the default behaviour, and the specs are meant to guarantee this on various systems, rather than for local changes. The same argument applies to the automatic handling of environment variables (though as long as they only add search paths, they should be harmless).
So I really recommend doing something "on top of" the gpc executable, e.g. a little wrapper script (batch file under Dos/Windows), or a shell alias (I think also command.com has something similar), if you don't want to use a Makefile or an IDE which lets you enter the options in a menu ...
In a slightly longer perspective, the compiler driver (`gpc') will be merged with `gcc' (the only difference probably being the automatic linking of the Pascal runtime), so any local changes we'd now make to `gpc' would not last very long, anyway.
This will be done after automake has been moved into a separate utility (which is necessary for GCC integration and to avoid some basic problems with automake that we currently can only kludge around and not really solve, and to make it more efficient). Automake is currently the big difference between `gpc' and `gcc' and once this difference is gone, the two can be merged easily.
This new utility (`gp') will also provide some facilities to handle global and user-specific options. It's not been released yet, but still it's better to do your options in a similar style already now. Everything you change locally in the compiler driver, specs etc. will later come to bite you ...
That said, for the special case of unit/object paths, it might be possible to read environment variables in the compiler proper (`gpc1'), since the compiler driver doesn't need them (unlike, e.g., LIBRARY_PATH). I'd have to check this in detail ...
Frank