Xref: utzoo comp.std.c:396 comp.lang.c:12734 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!rutgers!rochester!pt.cs.cmu.edu!k.gp.cs.cmu.edu!dwp From: dwp@k.gp.cs.cmu.edu (Doug Philips) Newsgroups: comp.std.c,comp.lang.c Subject: Re: C function prototyping and large projects. Keywords: prototyping, make, mks utilities Message-ID: <3036@pt.cs.cmu.edu> Date: 19 Sep 88 01:24:56 GMT References: <24@motto.UUCP> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 42 LineEaterHappiness++ I've used the following method on a medium sized project that run on PC clones under microsoft windows. The development environment started out as plain DOS (3.1) using MicroSoft C version 4.0. About 3 months into the project we switched to using the Mortice Kern systems package (ksh, diff, awk, sed, etc.). The microsoft compiler's ability to generate prototypes was the only mechanism used to generate prototypes. The underlying assumption was that the more that could be done automaticlly, the more it would be correct. For each source file F.c, there is a corresponding "internal interface" file F.i, which is the prototype output of the compiler having been run on F.c. This file is included only by F.c. Since the compiler was good enough to augment the prototypes with comments that indicate "global" functions, a simple script was used to extract the global routine prototypes into a file called "global.rtn", which was included by all source files. The rationale here is that since C would allow the function to be called anyway, it was best to make sure the prototypes were available. This meant adding new functions to a modules "external interface" was as easy as adding the routine and using it. Since it was too agonizingly slow to always compute these files, the makefile was doctored to break the dependency between F.c and F.i. Everytime I knew I made an interface change I would remove the F.i file. The rule for generating "global.rtn" would run a script. The script would generate a potential new file, but install it only if it was a change from the old version. About once a day, sometimes twice, I would remove all the generated files (.i, .o, etc) and let the world rebuild just to make sure. A good time to go get a coke, or whatever. Since then I've read a book called "Portable C and Unix System Programming" which had ideas similar to this. I don't remember the author (it's not in front of me now), but I THINK it was "Lapin". -Doug Philips ARPA: Doug.Philips@k.cs.cmu.edu -- Doug Philips "All that is gold does not glitter, Carnegie-Mellon University Not all those who wander are lost..." dwp@cs.cmu.edu -J.R.R. Tolkien