Path: utzoo!attcan!uunet!wuarchive!rex!uflorida!gatech!prism!gt4512c
From: gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L)
Newsgroups: comp.lang.c
Subject: Re: Splitting Turbo C library modules
Keywords: TurboC, libraries, modules
Message-ID: <19618@hydra.gatech.EDU>
Date: 14 Jan 91 13:03:43 GMT
References: <1991Jan12.222446.26899@odin.diku.dk> <350@bria>
Distribution: comp
Organization: Georgia Institute of Technology
Lines: 29

In article <350@bria> mike@bria.UUCP (Michael Stefanik) writes:
>In article <1991Jan12.222446.26899@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@prism
2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI)       |GTRI:jbrad@msd.gatech.
Marietta, Ga. 30067      |404 438-4181 (SCI)        |'...is this thing on..?'