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