olson@endor.harvard.edu (Eric Olson) (05/07/87)
Thank you all for many helpful suggestions! Many people mentioned that function prototypes should not be included in dependency files for make. This is a good solution, although I am always wary of leaving files out of makefiles. However, I am using LightSpeed C on the Mac, which does not allow me control over that information. The following reponse was mailed to me directly: >Date: Mon, 4 May 87 12:22:49 PDT >From: ll-xn!ames!styx!csi!csib!jwhitnel@harvard (Jerry Whitnell) >Organization: Communications Solutions Inc., San Jose, Ca > >Eric, I also use Lightspeed C on the Mac. My technique is to use seperate >prototype files for each c file. This has several advantages over one large >prototype file, including not rebuilding for each new function, tighter control >over which functions can call which other functions, etc. I even take it one >step further and add seperate .h files for prototypes local to a file vs. >global prototypes. All of this gives a "Modula-2" style of programming. > >Jerry This seems to be a good idea. I can turn on "Require Prototypes", and an error mearly indicates that I didn't think through what is calling what when I #include the prototype files. I will probably start using this technique soon: output.c has output.h (a standard .h file) and output.p (prototypes for local functions) and output.pp (or something) (public prototying information). If the function isn't in output.pp, no other module can use it. If it is, any module specifically includeing output.pp gets to see those functions. This is exactly the kind of scoping control that I have felt has been missing from C. Another mailed response: >Date: Mon, 4 May 87 12:05:29 pst >From: Henri J. Socha (x6251) <ames!drivax!socha@harvard> >Organization: Digital Research, Monterey > >1: Lightspeed C is fast. A complete recompile takes very little time. > (as much as doing only one module at work (Metware C).) So what's the matter? > >2: How often do you need to change the module header information? > Rare for me (relative to the number of re-compiles I do). > >3: By using <command> M and analysing the make dialog, I can selectively > make modules or not! I have not extensively tested it but, when > I disable! making a module I think this is remebered. > I.E. Lightspeed C now knows that changes do not effect the module. > (Can be forced to use most recent version info by selecting "Use Disk"). > >Well, I guess I've said enough. I still think Lightspeed C is the best >programming environment I know of. (Yes, I know of a few). >Only debugging, SCCS, and a high quality compiler are missing. >I feel you have given it a relatively bad presentation. > >And, yes, I set "prototypes enabled" except for those programmes >that I have no control over (others source). >In fact, I put Lightspeed's file proto.h into the respective >*.h files so that the default definition of string.h, etc. >would include full prototype information always. > >The gains far outway the hastle in my mind. >-- >UUCP:...!amdahl!drivax!socha WAT Iron'75 1. Yes, its fast, but I always want things to be more powerful and faster. A full recompile is no fun, especially when you know it isn't needed. I prototyped all the LightSpeed header files (by crunching MPW pascal headers), and that slows things down some too (not much, suprisingly). 2. I change the module header information every time I add a function. That's pretty often, for me, anyway. 3. I don't think the Make dialog remembers that you deselected a module. But regardless, this is not the sort of thing I like to do. If I have a make, I would like it to do that for me. That's what it's for. 4. I don't think I actually put Lightspeed into a bad light. Sorry if I did. I love it! Think Technology did a great job (and they know it). I REALLY don't want to turn anyone off to it. 5. Proto.h from Lightspeed? What is it? When I called, they said they didn't have prototypes for the Mac Libraries. Perhaps that's for the Unix style support library (which I don't use)? Once again, thanks to all for the comments. -Eric