On Wed, 2 Apr 1997 00:08:59 +0200 (MET DST) Peter Gerwinski peter@agnes.dida.physik.uni-essen.de wrote: [...]
(left-justified). To produce "_______123" you must explicitly say "writeln ( 123 : 10 );".
The Standard says that these default widths are implementation-dependent. There was a short discussion about whether GPC's behavior (default width 10 for Integers, 14 for Reals, 6 for Booleans) was a good decision. We soon agreed that it would be better to produce left-justified output when no width has been specified. Otherwise, you would have to say "writeln ( 123 : 1 );" to get the left-justified "123" which is clumsy and misleading. We forgot to post a copy of the discussion to the list; sorry about that.
In case you have some arguments to set it back to the previous state, just post it here. (These are only some constants in `rts/rts.h', so it was not much work to change. Perhaps (yet another) command-line switch would satisfy everybody?)
I think this could be the way forward. Having a multitude of command line switches is very good, in that it gives the programmer more flexibility to use the compiler in the way that he/she likes, not in the way that somebody else thinks they should. However, the price of flexibility is complexity. In case you haven't done this, can you introduce a .CFG file (like with Borland) where one can put all the command line switches that they want to use? The compiler will read the .CFG file before doing anything else, and will adjust its behaviour accordingly. I personally prefer this approach to using environment variables or the such. You can make many sample .CFG files (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people can then rename to GPC.CFG or whatever.
Sorry if all this already exists. I lurk in this list, because I am quite interested in GPC and its future (and its potential to release me from arbitrary decisions made by certain companies about where their compilers are going) but I am yet to fully utilise GPC myself.
Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk
On Wed, 2 Apr 1997, The African Chief wrote:
I think this could be the way forward. Having a multitude of command line switches is very good, in that it gives the programmer more flexibility to use the compiler in the way that he/she likes, not in the way that somebody else thinks they should. However, the price of flexibility is complexity. In case you haven't done this, can you introduce a .CFG file (like with Borland) where one can put all the command line switches that they want to use?
You can do all of this in a Makefile.
The compiler will read the .CFG file before doing anything else, and will adjust its behaviour accordingly. I personally prefer this approach to using environment variables or the such. You can make many sample .CFG files (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people can then rename to GPC.CFG or whatever.
Sorry if all this already exists.
Environment variables are used to override default paths to libraries etc. Commandline switches are used to select compiler behaviour (optimization, debugging, dialect etc.)
For unix, setting environment variables is usually not necessary because you build your own compiler with "taylormade" defaults hardcoded in the compiler binary.
For MS-DOS, the compiler is often downloaded as a binary and installed in a path other than the one specified at compile time. DJGPP has an elegant solution for them: `djgpp.env'. That way, you don't have to clutter your MS-DOS environment with a lot of environment variables.
Remaining are cygwin32 and OS/2 platforms. cygwin32 is still experimental, maybe they implement something like `djgpp.env'.
GPC has a config file: `specs'. You can change some of GPC's behaviour here. Future versions of GPC may come with different driver binaries (`gpc', `bpc', `epc' etc.) which preset a number of switches to select a certain Pascal dialect.
Greetings, JanJaap
--- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming]
On Wed, 2 Apr 1997 00:08:59 +0200 (MET DST) Peter Gerwinski peter@agnes.dida.physik.uni-essen.de wrote:
[...]
In case you have some arguments to set it back to the previous state, just post it here. (These are only some constants in `rts/rts.h', so it was not much work to change. Perhaps (yet another) command-line switch would satisfy everybody?)
I think this could be the way forward. Having a multitude of command line switches is very good, in that it gives the programmer more flexibility to use the compiler in the way that he/she likes, not in the way that somebody else thinks they should. However, the price of flexibility is complexity. In case you haven't done this, can you introduce a .CFG file (like with Borland) where one can put all the command line switches that they want to use? The compiler will read the .CFG file before doing anything else, and will adjust its behaviour accordingly. I personally prefer this approach to using environment variables or the such. You can make many sample .CFG files (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people can then rename to GPC.CFG or whatever.
Oh, No! Please don't. Why don't we handle this like it is used in the common place way at unixish Systems: Take a Makefile and put a line PFLAGS (is this right?) in it. There you have all your flags, you think you need. Let's say there is a PBORLANDFLAGS=--borland-pascal --what-in-hell-else-is-needed-for-borland and a PMYFLAGS=--left-justified --enable-foo-warnings. Then you can put them together to the archive your program comes with and nobody needs to edit the GPC.CFG.
What one might do is put sample Makerules-file(s) to the GPC distribution.
Bye, Nils