reg@lti.com (Rick Genter x18) (10/22/88)
In article <105@dalcsug.UUCP>, dalcs!dalcsug!dalegass@uunet.uu.net (Dale Gass) writes: > My personal preference when using prototypes, is to put all the prototypes > into one header file (proto.h, or whatever), which is included by all modules > in the project; however, I don't declare the dependency of all the source > files upon proto.h. This is a far from optimal solution. On several large (50,000+ LOC) industrial projects I've worked on we've taken the approach that each .c file has a corresponding .i file that defines the .c file's external interface. Every .o file depends implicitly on its .c and .i, as well as the .i files of the other modules it uses. This gives more of a module flavor to C and makes it quite explicit as to what services a particular module is importing (and exporting, for that matter). The advantage of this approach is that, since each .c includes its own .i, when an interface changes you have to modify the .i for the .c to recompile, and thus cause all of the other affected .c's to get recompiled. Furthermore, when an interface changes it is simple to determine which files need to be modified to reflect that change (worst case: grep for #include "foo.i" in all of your .c's). In terms of managing dependencies, that's what tools are for. Before there was "cc -M" I wrote a tool called "dodepend" that generated the back half of a Makefile. With "dodepend" I have been able to have a single standard Makefile for virtually every project I've worked on; I simply define different "SRCS" and "OBJS" (and maybe "LIBS") macros for the different projects. A single "proto.h" is like Sun's <suntool/sunview.h>, which brings in everything (or, almost everything :-() and tells you nothing about what services the program is actually trying to use. This becomes a real pain to maintain. Trust me. :-) - reg -- Rick Genter ...!{buita,bbn}!lti!reg Language Technology, Inc. reg%lti.uucp@bu-it.bu.edu 27 Congress St., Salem, MA 01970 (508) 741-1507