On Wed, 28 May 1997 19:41:17 +0200 (MET DST) Peter Gerwinski peter@agnes.dida.physik.uni-essen.de wrote:
Is it possible to tell which GPC platform and version is being used? [...] This would really help in writing portable code. What do you think?
I agree in complete. Let's ask the list what they think, but I am almost sure that everybody will agree.
Ok. I am sending this response to the list.
[...] So, can this be done with GPC? It would help with a lot of things, e.g., in the SYSTEM unit - so, could we have these pre-defined in GPC; __LINUX__ __UNIX__ __DJGPP__ (or __MSDOS__) __EMX__ (or __OS2__) __WIN32__ (or __CYGWIN__)
- depending on which GPC port you are using.
Since `__MSDOS__' is ambiguous and with EMX one and the same executable runs on DOS as well as on OS/2 making this a run-time, not a compile-time decision, I vote for `__DJGPP__' and `__EMX__' rather than `__MSDOS__' and `__OS2__'.
Yes, I agree.
Since I agree with "xxxx" that Windows 95/NT is not a "win" in the sence of hacker's speech (see `jarg400.info.gz' from the GNU distribution), but Cygnus is, I'd vote for `__CYGWIN__' rather than `__WIN32__', although "Win32" is the official name of that API.
Yes, "__CYGWIN__" seems fine.
and you could have; __VER20__
or whatever, depending on the GPC version.
Here I'd prefer to use the GNU convention and define the `__GPC__' symbol to be `2' and `__GPC_MINOR__' to be `0'.
I am not sure I understand how this works.
This also avoids confusion with Borland Pascal 4.0 once we reach that version number.
There would be no confusion, because BP doesn't include the leading and trailing "__". TP 4.0 would have "VER40" defined. GPC 4.0 would have "__VER40__" defined.
Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.50 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk
Is it possible to tell which GPC platform and version is being used? [...] This would really help in writing portable code. What do you think?
Please check what gpc (gcc) defines now in your system.
This is most easily done by creating an empty file, say foo.p, and compiling it with the '-v' option. In a unix system, you can do this with:
# touch foo.p # gcc -v foo.p
At least in the version I compiled yesterday for the Alpha, the defines are:
/v/dunix40_alpha/gnu/gcc/2.7.2.1/lib/gcc-lib/alpha-dec-osf4.0/2.7.2.1/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=970528(2 -D__GPC__=970528(2 -D__GNUC_MINOR__=7 -D__unix__ -D__osf__ -D__alpha -D__alpha__ -D_LONGLONG -D__SYSTYPE_BSD__ -D_SYSTYPE_BSD -D__unix -D__SYSTYPE_BSD -Asystem(unix) -Asystem(xpg4) -Acpu(alpha) -Amachine(alpha) -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C /tmp/foo.p /tmp/ccaagopa.i GNU CPP version 970528(2.7.2.1)
So, it seems that the __GPC__ define at least will get screwed up, if it is generated like it is now.
Also, please consider using assertions (see manual) instead of defines if you need something that works only in e.g. '#if' constructs, but does not expand in the code.
Also, I'd recommend in using the same definitions as are defined for the GCC for the same host. Why add new ones?
Happy hacking!
Juki jtv@hut.fi
A couple of bugs from the 970510 snapshot I compiled but did not yet test very much:
Please check the use of strncmp() functions in the code. At least in the gpc-lex.c and gpc-decl.c there are calls (9?) to this function without the length parameter. Trivial to fix, so I don't bother you with a diff.
The generated Makefile does not search the gpc-gperf.c from the source directory, but rather unnecessarily requires the use of the gperf program to generate the hash table, if gpc is not compiled in the source tree.
Some other problems in the Makefile: - 'make' command makes only the gpc-common.o because the order of the rules is incorrect. 'make all' works better. Please re-order the rules.
- I don't think it's a good idea to install libgcc.a always when installing gpc. You could e.g. install it only if it does not exist in the destination directory.
- When I did 'make install' the compiler was recompiled again without reason. I did not yet check why this happened, has anyone else seen this?
On Thu, 29 May 1997, The African Chief wrote:
On Wed, 28 May 1997 19:41:17 +0200 (MET DST) Peter Gerwinski peter@agnes.dida.physik.uni-essen.de wrote:
Is it possible to tell which GPC platform and version is being used? [...] This would really help in writing portable code. What do you think?
I agree in complete. Let's ask the list what they think, but I am almost sure that everybody will agree.
Ok. I am sending this response to the list.
[...] So, can this be done with GPC? It would help with a lot of things, e.g., in the SYSTEM unit - so, could we have these pre-defined in GPC; __LINUX__ __UNIX__ __DJGPP__ (or __MSDOS__) __EMX__ (or __OS2__) __WIN32__ (or __CYGWIN__)
- depending on which GPC port you are using.
They *are* defined Run gpc -v and see what's defined if gpc-cpp is executed.
Since `__MSDOS__' is ambiguous and with EMX one and the same executable runs on DOS as well as on OS/2 making this a run-time, not a compile-time decision, I vote for `__DJGPP__' and `__EMX__' rather than `__MSDOS__' and `__OS2__'.
Yes, I agree.
Since I agree with "xxxx" that Windows 95/NT is not a "win" in the sence of hacker's speech (see `jarg400.info.gz' from the GNU distribution), but Cygnus is, I'd vote for `__CYGWIN__' rather than `__WIN32__', although "Win32" is the official name of that API.
Yes, "__CYGWIN__" seems fine.
No. Read back the cygwin32 mailinglists. cygwin32 defines __CYGWIN32__ for code specific for the cygwin32 environment. It also defines _WIN32 for the more generic win32 dependencies. It used to define __WIN32__ but they don't do that anymore because they figured out that cygwin.dll wasn't presenting a WIN32 API (that's in kernel32, user32.dll etc. from M$)
DJGPP specific stuff (read: _go32_xxx and _dpmi_xxx functions) are best surrounded by __DJGPP__ MS-DOS related code (lets's see, something about CRLF conversions for example) should be surrounded by __MSDOS__ because it applies to EMX too.
and you could have; __VER20__
or whatever, depending on the GPC version.
See __GPC_MAJOR__ and __GPC_MINOR__
Greetings, JanJaap
--- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.
-
Jan-Jaap van der Heijden -
Jukka Virtanen -
The African Chief