Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!usc!cs.utexas.edu!asuvax!ncar!dinl!noren From: noren@dinl.uucp (Charles Noren) Newsgroups: comp.lang.c++ Subject: Re: best extension for C++ files Message-ID: <1729@dinl.mmc.UUCP> Date: 11 Sep 90 22:08:35 GMT References: <907@zinn.MV.COM> <1845@cs.rit.edu> <3358@stl.stc.co.uk> <1990Sep08.094000.10269@virtech.uucp> <144@tdatirv.UUCP> <451@taumet.com> Reply-To: noren@dinl.UUCP (Charles Noren) Organization: Martin Marietta I&CS, Denver CO. Lines: 31 In article <451@taumet.com> steve@taumet.com (Stephen Clamage) writes: ...some stuff from another person about including general suffix rules to build .o files out C and C++ files. >If you include a build line for each file (or for each file of either C >or C++ at minimum), it doesn't matter that the file endings are the same. That is probably the best way in terms of making self-documenting build environments, but I'm wierd (if you haven't guessed already :-)). I've got a general makefile that looks at source in a directory and the directory name to determine what to build and how to build it. What to build is determined by directory suffix name (e.g., ".edir" for executable, ".ldir" for library, ".odir" for object-module, etc), and the componant to build from is determined from all the source files with known suffixes in the directory (information is also passed from the makefile in the higher level directory on libraries and include directories). In other words, I've got a makefile that knows how to build anything that follows my twisted conventions (I'm lazy, I hate to edit makefiles, and of course this doesn't work on MS-DOS). For me, standardized extensions for C++ files would be nice. Right now I have the minor inconvenience of having the several C++ suffixes in my makefile suffix list and duplicate the "make object from a C++ file" rule for each suffix. -- Chuck Noren NET: dinl!noren@ncar.ucar.edu US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260, Denver, CO 80201-1260 Phone: (303) 971-7930