On 14 Nov 2002 at 11:34, J. David Bryan wrote:

[...]

...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. It might be easier to reinstate it than to add processing for equivalent environment variables (and specs processing is more flexible as well).

Except that if one accidentally screws up the "specs" file, not only GPC, but everything else will be broken. Something added to the GPC driver can only affect GPC, and hence is a safer option.

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

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

Prof A Olowofoyeku (The African Chief) wrote:

On 15 Nov 2002 at 18:51, Frank Heckenbach wrote:

[...]

...

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.

What is the time scale for this? I have already written the code for the GPC driver to read 5 extra environment variables (to cater for "-- unit-path", "--object-path", "--unit-destination-path", "--object- destination-path", and "--executable-path").

Unfortunately, the latter 3 are not ok because (a) they're needed by the driver and (b) they may break compilation of 3rd party packages (which don't expect their objects to go somewhere else; whereas adding a search path (at the end) won't make a difference unless a file is not found otherwise which would be a problem, anyway).

The code is actually quite simple (I am sure it can be significantly improved), and not very long (I have a patch ready for anyone who is interested). One can continue to use the patch until the gpc and gcc drivers are merged and the "gp" utility is ready.

Well, if you think so. But then please do handle all support requests resulting from it (now and in the future when things are changed). I don't want to waste my time with such local changes. And please put a clear note in the version message etc. to describe this change, to avoid confusing anyone who switches between this and an unpatched version.

[...]

...

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

Please let us know when you have ascertained this. It is better for this type of thing to be implemented centrally (i.e., in GPC itself) than via local changes.

Indeed. I'll now implement environment variables GPC_UNIT_PATH and GPC_OBJECT_PATH (names alright?) which if set are added at the *end* (see above) of the respective paths. I'll probably not use them myself, and therefore won't test them very well, so you might want to after the next release.

Frank

On 15 Nov 2002 at 18:51, Frank Heckenbach wrote:

The `gpc1' spec was removed, not specs processing in general.

My apologies for the confusing wording. I was trying to recall the Changelog entry from memory.

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

Actually, I understand quite well.

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

Global paths in all cases.

...and certainly not a dialect option.

I do not want to debate philosophy, but I disagree with your statement. Dialect is something I do want to set on a global basis. It does no good when five members of a team are developing an Extended Pascal program if the sixth has been unintentionally using GNU Pascal dialect options (because the compiler has been defaulting to GP dialect) and so produces a program section incompatible with EP. GPC used to provide separate drivers so that, e.g., one could delete all but the EP (default) driver to ensure that users wouldn't accidentally put the compiler in GNU Pascal mode. That had been eliminated, so I fell back on configuring the spec to default to EP, and now that too has been eliminated.

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.

Such errors usually don't mystify me, because I explicitly add "--gnu- pascal" to the compiler invocation when attempting to use GPC-related packages. The point is that we want to use EP company-wide and don't want someone accidentally producing invalid EP (but valid GNU Pascal) because of the compiler defaults. It is perfectly acceptable for a user to override the EP default by specifying, e.g., "--gnu-pascal" on the command line, but we don't want GPC accepting anything other than EP unless asked for explicitly by user action.

Therefore, invoking `gpc' should exhibit the default behaviour, and the specs are meant to guarantee this on various systems....

It's fine that many, or perhaps most folks want to default to GNU Pascal, and it's fine that the specs supplied with GPC default as you wish. That isn't what we're trying to achieve, however.

...rather than for local changes.

"Local," in this case, meaning "company-wide."

So I really recommend doing something "on top of" the gpc executable, e.g. a little wrapper script (batch file under Dos/Windows)....

The problem with little wrapper scripts is that they can be bypassed unintentionally (e.g., someone forgets to use "our-gpc" and uses "gpc" directly, or changes their local PATH so that the wrapper directory appears after the GPC directory, etc.).

Everything you change locally in the compiler driver, specs etc. will later come to bite you ...

Thank you for the warning.

-- Dave

J. David Bryan wrote:

Dialect is something I do want to set on a global basis. It does no good when five members of a team are developing an Extended Pascal program if the sixth has been unintentionally using GNU Pascal dialect options (because the compiler has been defaulting to GP dialect) and so produces a program section incompatible with EP. GPC used to provide separate drivers so that, e.g., one could delete all but the EP (default) driver to ensure that users wouldn't accidentally put the compiler in GNU Pascal mode.

Well, here's your `epc' driver for bash:

#!/bin/sh gpc --extended-pascal "$@"

and for command.com (something like this; haven't written batch scripts for quite a while ...):

@echo off gpc --extended-pascal %1 %2 %3 %4 %5 %6 %7 %8 %9

As for removing the gpc executable, I wonder whether you need to patronize your coworkers (they're programmers I assume). Do you remove all other programs that aren't regularly used? But anyway, you could rename the gpc executable to gpc.orig or something (and adjust the wrapper script, of course), so accidentally calling gpc won't work. This has the advantage, when trying to compile something that demands gpc, it will just fail with `gpc not found' or something like this rather than some obscure errors. IOW, if you don't want to have a GPC-dialect compiler (directly invokable), there should simply be no program called `gpc'.

The reason why I'm somewhat sensitive on these matters is that I often get bug reports regarding GPC or some Pascal programs, and sometimes it turns out, often after long debugging, that they were caused by some "local changes" and things like that. I don't like to waste my time this way. So I try to encourage (strongly ;-) people not to make their changes in obscure ways or even distribute changes made in obscure ways. If that isn't accepted, the alternative, at least in the long run, is for me to simply ignore all reports I can't easily reproduce. (I don't know if your changes have caused any problems -- I don't want to check the archives now ... --, but since there are more people who like to suggest such changes, I mean this as a general comment.)

Frank

J. David Bryan wrote:

...

(I don't know if your changes have caused any problems....

I have reported four problems to the GPC list, with these subjects:

• Compiling gpc-19991030 fails on rts.c (2000-01-20)
• [Bug] GPC_EXEC_PREFIX doesn't take precedence (2000-08-07)
• Bad "stabs" prevent debugging (2002-04-23)
• Cannot display variables with GDB (2002-08-27)

Before reporting each, I have reproduced the problem on an OOTB copy of GPC (credit me with a small bit of intelligence here :-).

As I said, I didn't want to offend you personally, but since you posted your suggestions to a public list, chances are that someone else picks them up who doesn't take the proper precautions with future bug reports.

Frank