Splitting Turbo C library modules

[BRADBERRY,JOHN L]

In article <350 at bria> mike at bria.UUCP (Michael Stefanik) writes:
>In article <1991Jan12.222446.26899 at odin.diku.dk> diku.dk!fedtmule (Jens Markussen) writes:
>[text deleted]... Is it reasonable
>for you to require that I recompile *everything* when all that was done was
>changing one line of code in one function?  As far as coordinating what gets
>compiled and what doesn't, this is what 'make' is for.
>
>The whole strength of C is portability and modularity; by keeping everything
>all lumped together, you're defeating the elegance and power of the language
>and the tools used with it.

Actually, the single function/module issue must be faced on virtually ALL
high level languages. Generally speaking, it is considered good practice to
sprinle functions over small individual files for ease of maintenance. How-
ever, a limit can be reached when you consider larger systems where several
THOUSAND functions are contained in many different library groups!

In this case, a compromise of function 'groupings' may be considered over
infinite directory tree structures.

By the way, how about a compiler/linker/make system where an individual
file 'within' a module is automatically located and exclusively compiled as
changes are made...what an interesting nightmarish programming problem!

-- 
John L. Bradberry        |Georgia Tech Research Inst|001100110011001100110011
Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c at prism
2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI)       |GTRI:jbrad at msd.gatech.
Marietta, Ga. 30067      |404 438-4181 (SCI)        |'...is this thing on..?'