throopw@dg_rtp.UUCP (05/06/87)
> steele@unc.cs.unc.edu (Oliver Steele) >} Eric Olson (olson@endor.UUCP) >) Harry J. Gross (hjg@bunker.UUCP) >> Tom Stockfisch tps@sdchemf.UUCP > [about putting all the prototypes in a single header file] >}.... So I can prototype >}everything in a header file included in all my modules, but then adding a >}module forces a complete re-make. >) you could *touch* each of the other modules (.c and .obj). >>The way I handle it is to have my declaration/prototype header file contain >>*only* declarations/prototypes, and then I DON'T MENTION IT IN THE MAKEFILE. > The way I handle it, when I'm being modern and verbose, is to treat each > set of functions/globals that implements and abstract type or object Foo as > a module 'Foo' contained in two files, 'foo.c' and 'foo.h' [...] This is also how I do it. There are, of course, problems with this, as in what about .h files that need types from other .h files, and who should include what when to make it all transparent, but these problems are relatively minor. >>The way you mess up in this case is to change a function's type in its >>module and forget to change it in the header file. Mentioning the header file >>in the "Makefile" doesn't catch this error. > Including a module's header in its code file solves that. The only problems > I've run into are in the management of modules large enough to be composes > of submodules. Better still is automatically *creating* the .h file from the .c file. In such a scheme, a parser would discover every typedef, variable, and routine declared external, and generate an appropriate declaration in the .h file. A poor man's version can be had fairly simply by using conditional macro expansion around declarations to be exported into the .h file. -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." --- Edsgar Dijkstra -- Wayne Throop <the-known-world>!mcnc!rti!dg_rtp!throopw