matt@iquery.UUCP (Matt Reedy) (08/05/88)
We had a discussion a few months ago about the [in]compatiblity of the
System V.3 cpp and VMS #include syntax, but I forgot the outcome :^).
The problem is the following: I want the same source to compile on both
SysV and VMS, so I use this style:
#ifdef VAX
#include file
#include stdio
#else
#include <fcntl.h>
#include <stdio.h>
#endif
On the VAX, the '#include file' and '#include stdio' syntax is valid and
references members of a text library. However, my 3B2 cpp chokes on these
lines with 'bad include syntax' even though the symbol VAX is NOT DEFINED.
Is there an easy workaround?
matt
--
Matthew Reedy UUCP: {harvard!adelie,gatech!petro}!iquery!matt
Programmed Intelligence Corp. "Lots of people without brains do alot of talking"
400 N Loop 1604 E, Suite 330 Scarecrow - "Wizard of Oz"
San Antonio, TX 78232 (512) 490 6684moore@utkcs2.cs.utk.edu (Keith Moore) (08/05/88)
In article <134@iquery.UUCP>, matt@iquery.UUCP (Matt Reedy) writes: > The problem is the following: I want the same source to compile on both > SysV and VMS, so I use this style: > > #ifdef VAX > #include file > #include stdio > #else > #include <fcntl.h> > #include <stdio.h> > #endif > > On the VAX, the '#include file' and '#include stdio' syntax is valid and > references members of a text library. However, my 3B2 cpp chokes on these > lines with 'bad include syntax' even though the symbol VAX is NOT DEFINED. > > Is there an easy workaround? Sure. Just use #ifdef vms #include <file.h> #include <stdio.h> #else ... for VMS also. The VMS systems I have seen put copies of these files in sys$library:, and the C compiler knows to search for include files there. This may be an option, however. At worst, you can extract them from sys$library:vaxcdef.tlb with the LIBRARY command, as in: $ lib/extract=file sys$library:vaxcdef.tlb $ rename vaxcdef.txt file.h ...and use the #include "filename" syntax, or the /INCLUDE= command line qualifier. BTW, you might prefer to use #ifdef vms rather than #ifdef VAX. *Some* VAXen run a different operating system. :-) ...embarassed that I know this much about the VMS C compiler... Keith Moore UT Computer Science Dept. Internet/CSnet: moore@utkcs2.cs.utk.edu 107 Ayres Hall, UT Campus BITNET: moore@utkcs1 Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822 -- Keith Moore UT Computer Science Dept. Internet/CSnet: moore@utkcs2.cs.utk.edu 107 Ayres Hall, UT Campus BITNET: moore@utkcs1 Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822
swilson%thetone@Sun.COM (Scott Wilson) (08/06/88)
In article <134@iquery.UUCP> matt@iquery.UUCP (Matt Reedy) writes: >The problem is the following: I want the same source to compile on both >SysV and VMS, so I use this style: > >#ifdef VAX >#include file >#include stdio >#else >#include <fcntl.h> >#include <stdio.h> >#endif > >Is there an easy workaround? I have worked on a few projects that compiled and ran on both Suns and VMS with little or no special precautions. Two of these projects used lex and yacc output. The solution to your problem is simple, use the <*.h> form for both. The VMS C compiler has no problem with UNIX style #includes (it even allows pathnames with '/' for compatibilty, I think). Also, if you set some logical that I don't remember, you can also use the <sys/*.h> form and have the compiler look in the same directories as it does for other standard include files. As for the two environments using different file names for the same declarations, I guess you'll have to use and #ifdef for that. One of the compatibility problems I ran into was compiling lex output on VMS. In UNIX, stdin, stdout, stderr are compile time constants, however in VMS they're not so you can't use them as initializers. This was solved by having the Makefile run sed to remove the offending initialization and then explicitly do it in the beginning of main(). Another problem was that lex output wants to include "stdio.h" as opposed to <stdio.h> and VMS is somewhat screwed about how these differ. This was solved by setting c$include to be the same as vaxc$include. -- -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA
ok@quintus.uucp (Richard A. O'Keefe) (08/06/88)
In article <134@iquery.UUCP> matt@iquery.UUCP (Matt Reedy) writes: >The problem is the following: I want the same source to compile on both >SysV and VMS, so I use this style: >#ifdef VAX >#include file >#include stdio >#else >#include <fcntl.h> >#include <stdio.h> >#endif >[V.3 cpp dislikes the first two #includes] (1) That should be #ifdef vms, not #ifdef VAX. VAXen run 4.?BSD, Ultrix, and some flavour of System V, as well as VMS. (2) While #include stdio and #include <stdio.h> do mean different things in VAX-11 C (check the manual) the latter form _is_ accepted and will work unless you've gone out of your way to break it. You should be able to convert to #ifdef vms #include <file.h> #include <stdio.h> #else #include <fcntl.h> #include <stdio.h> #endif and have it work on both. (We had to do this for quite a lot of files; what makes it particularly galling is that the vms #includes caused no trouble in V.2. Sometimes I wonder about AT&T.) (3) Another possibility is to use some other preprocessor. For example, stuff your program through the GNU "C Compatible Compiler Preprocessor (CCCP)", and give the result to AT&T's compiler.
jkingdon@chinet.chi.il.us (James Kingdon) (08/06/88)
In article <134@iquery.UUCP> matt@iquery.UUCP (Matt Reedy) writes: >The problem is the following: I want the same source to compile on both >SysV and VMS, so I use this style: > >#ifdef VAX >#include file >#include stdio >#else >#include <fcntl.h> >#include <stdio.h> >#endif > >On the VAX, the '#include file' and '#include stdio' syntax is valid and >references members of a text library. However, my 3B2 cpp chokes on these >lines with 'bad include syntax' even though the symbol VAX is NOT DEFINED. Well, one way around is #ifdef VAX #include <vaxstuff.h> #else #include <fcntl.h> #include <stdio.h> #endif and in vaxstuff.h #include file #include stdio A non-vax system V.2 has no problems with this. (By the way, VAX includes Ultrix, not just VMS. Not that this necessarily matters in this case).
leo@philmds.UUCP (Leo de Wit) (08/06/88)
In article <134@iquery.UUCP> matt@iquery.UUCP (Matt Reedy) writes: >We had a discussion a few months ago about the [in]compatiblity of the >System V.3 cpp and VMS #include syntax, but I forgot the outcome :^). > >The problem is the following: I want the same source to compile on both >SysV and VMS, so I use this style: > >#ifdef VAX >#include file >#include stdio >#else >#include <fcntl.h> >#include <stdio.h> >#endif > >On the VAX, the '#include file' and '#include stdio' syntax is valid and >references members of a text library. However, my 3B2 cpp chokes on these >lines with 'bad include syntax' even though the symbol VAX is NOT DEFINED. > >Is there an easy workaround? Yes, there is. Change it into: #include <stdio.h> #ifdef VAX #include <file.h> #else #include <fcntl.h> #endif The files stdio.h and file.h should reside in the directory SYS$LIBRARY, as should the other standard include files. (Don't know about text libraries, but I would not use them if they insisted on such a weird syntax, invoking all kinds of portability problems). Leo.
robert@pvab.UUCP (Robert Claeson) (08/07/88)
In article <134@iquery.UUCP>, matt@iquery.UUCP (Matt Reedy) writes: > The problem is the following: I want the same source to compile on both > SysV and VMS, so I use this style: > #ifdef VAX > #include file > #include stdio > #else > #include <fcntl.h> > #include <stdio.h> > #endif > On the VAX, the '#include file' and '#include stdio' syntax is valid and > references members of a text library. However, my 3B2 cpp chokes on these > lines with 'bad include syntax' even though the symbol VAX is NOT DEFINED. The VAX/VMS C Compiler uses '#include module' to read header files out of a text library, where they are stored in compressed form and thus takes less disk space. It can also use the normal '#include <file>' and '#include "file"' directives to include files. This does not work in older versions of the VMS C Compiler, but if you have a maintenace contract, you would be able to upgrade fairly easy. The solution I used and my former place of employment, was to simply extract the header files from the text library and place them in a directory, as described in the manual. Good luck. _______________________________________________________________________________ Robert Claeson Tel: +46 8-7300300 PVAB Fax: +46 8-7301567 P.O. Box 4040 Eunet: robert@pvab.se S-171 04 Solna, Sweden Uucp: {uunet,mcvax}!enea!pvab!robert
darin@nova.laic.uucp (Darin Johnson) (08/09/88)
In article <134@iquery.UUCP>, matt@iquery.UUCP (Matt Reedy) writes: > We had a discussion a few months ago about the [in]compatiblity of the > System V.3 cpp and VMS #include syntax, but I forgot the outcome :^). > > The problem is the following: I want the same source to compile on both > SysV and VMS, so I use this style: > > #ifdef VAX > #include file > #include stdio > #else > #include <fcntl.h> > #include <stdio.h> > #endif > I wonder why DEC likes to push this format. Obviously, it is not clear enough in the C manual that the following are EQUIVALENT! #include stdio and #include <stdio.h> I have all my VMS software using the angle-brackets with absolutely no problem. Leaving the brackets off speeds up access by a miniscule fraction. I feel this is a serious documentation problem with DECs C manual. None of the examples in the manual use the angle brackets, which is probably why I see so many people with the impression that they aren't allowed. So I would change the code above to read: #ifdef VMS #include <file.h> #else #include <fcntl.h> #endif #include <stdio.h> (notice that I have #ifdef VMS instead of #ifdef VAX!) Also, if you define the logical name SYS to point to SYS$LIBRARY, then you can also have statements like "#include <sys/file.h>", which makes for easier porting. Darin Johnson (...pyramid.arpa!leadsv!laic!darin) (...ucbvax!sun!sunncal!leadsv!laic!darin) "All aboard the DOOMED express!"
hjm@cernvax.UUCP (hjm) (08/10/88)
#include foobar
#include <foobar.h>
are not the same if foobar is a logical name! Using logical
names allows for greater flexibility in where include files are
kept (you may not want them kept with all the others because of a
name conflict, or perhaps you just want to be tidy), whereas the
<foobar.h> form is an absolute address.
I have spent a lot of time reorganising disks after several
head-crashes and logical names were easy to change to different
locations, but changing absolute addresses which referred to
files by disk and directory were *much* more troublesome. If you
don't have the source for a program, then try to find out what
files it accesses and where, and then change it without logical
names.
I'm redirecting followups to comp.os.vms as this is a VMS issue,
and not a lot to do with C (thank god!).
Hubert Matthewsbronson@mfci.UUCP (Tan Bronson) (08/12/88)
In article <134@iquery.UUCP> matt@iquery.UUCP (Matt Reedy) writes: > <The problem is the following: I want the same source to compile on both <SysV and VMS, so I use this style: < <#ifdef VAX <#include file <#include stdio <#else <#include <fcntl.h> <#include <stdio.h> <#endif < <On the VAX, the '#include file' and '#include stdio' syntax is valid and <references members of a text library. However, my 3B2 cpp chokes on these <lines with 'bad include syntax' even though the symbol VAX is NOT DEFINED. < try this #ifdef VAX #define FILE file #else #define FILE <fcntl.h> #endif #include FILE Most people I mentioned this to, were surprised this worked, so maybe VMS will not allow it (It broke my makefile generator) ~ >Is there an easy workaround? > >matt >-- >Matthew Reedy UUCP: {harvard!adelie,gatech!petro}!iquery!matt >Programmed Intelligence Corp. "Lots of people without brains do alot of talking" >400 N Loop 1604 E, Suite 330 Scarecrow - "Wizard of Oz" >San Antonio, TX 78232 (512) 490 6684 Tan Bronson Multiflow Computer Inc UUCP(work): {yale,uunet}!mfci!bronson 175 N Main St UUCP(home): {yale,mfci}!bronson!tan Branford, Ct 06405 Phone(work):(203)-488-6090
lew@gsg.UUCP (Paul Lew) (08/12/88)
From article <792@cernvax.UUCP>, by hjm@cernvax.UUCP (hjm): > > #include foobar > #include <foobar.h> > > are not the same if foobar is a logical name! Using logical > names allows for greater flexibility in where include files are > kept (you may not want them kept with all the others because of a > name conflict, or perhaps you just want to be tidy), whereas the > <foobar.h> form is an absolute address. > Is there a version of cpp that will use Unix environment variables for include file names? This is something I like to have for a long time. The imake utility ditributed with X11 uses cpp symbols as the include file names. You may do something like: #ifdef vms #else #define foobar <foobar> #endif #include foobar This works for BSD, 3B2, and Xenix systems. I like it because you can do things like: #ifdef BSD #define String_h <strings.h> #else #define String_h <string.h> #endif and put all these in one file. There is no need to do #ifdef in every C files!! However, this works only if there is one to one mapping of the inlcude file which unfortunately is not true for a lot of them. Any remedy? -- Paul Lew {oliveb,harvard,decvax}!gsg!lew (UUCP) General Systems Group, 5 Manor Parkway, Salem, NH 03079 (603) 893-1000
ok@quintus.uucp (Richard A. O'Keefe) (08/13/88)
In article <229@gsg.UUCP> lew@gsg.UUCP (Paul Lew) writes: >Is there a version of cpp that will use Unix environment variables for >include file names? This is something I like to have for a long time. Suggestion: you don't _have_ to do everything with cpp. Write a program that extracts the variables of interest from the environment and writes a header file. For example, I just knocked together the following Bourne shell script to do this (10 minutes, 5 minutes needed to check the manual because I normally use csh): #!/bin/sh # FILE : zabbo # USAGE : zabbo var.... >foobaz.h # EFFECT: # For each var in turn, # if var is defined, then #define var "$var" is written. # otherwise, #undef var is written. # EXAMPLE: zabbo TERM HOME >env.h d='$' q='"' for var do eval "def=is_$d{$var+defined} val=$d{$var-}" if [ $def = is_defined ] then echo "#define $var $q$val$q" else echo "#undef $var" fi done Here's an example: % zabbo TERM HOME NONESUCH >env.h % cat env.h #define TERM "sun" #define HOME "/goedel/ok" #undef NONESUCH How can you use this to select the appropriate header file? Suppose you have an environment variable STRINGS_HDR="<strings.h>" # or whatever then you create a header file with % zabbo STRINGS_HDR ...others... >env.h and in your C program do #include "env.h" #include STRINGS_HDR This works in 4.2, V.2, and V.3. There is no end to the places you might want to get definitions for C macros. This technique of writing a program to extract the information and repackage it for CPP can be used for other things than looking up the environment, and keeps CPP simple.