fedtmule@diku.dk (Jens Markussen) (01/13/91)
Hi, I'm writing a collection of Turbo-C functions. These are still all contained in one single source-file (makes it easy - sharing variables and so forth). Compiling this file naturally generates one object file. Now, I'm trying to make a library-file (.lib-file) out of these functions. Using the TLIB program adds the entire object file as one module. This means that my programs, even if using only a few of the functions, will need to link the entire module into the executable file. I'm looking for a way to add my functions, with the functions acting as separate modules (same style that Borlands uses in their libraries (cs.lib..)), but without having to split my sources-file into lots of small files. Any clues as to how this could be done, would be appreciated.... --------------------------------------------------------------------------- Jens Markussen (fedtmule@diku.dk) ---------------------------------------------------------------------------
mike@bria.UUCP (Michael Stefanik) (01/14/91)
In article <1991Jan12.222446.26899@odin.diku.dk> diku.dk!fedtmule (Jens Markussen) writes: > I'm looking for a way to add my functions, with the functions acting >as separate modules (same style that Borlands uses in their libraries >(cs.lib..)), but without having to split my sources-file into lots of small >files. Any clues as to how this could be done, would be appreciated.... I'm not big on DOS C compilers, but the philsophy should be same ... different functions should be kept in different sources; this is good taste and makes life a whole lot easier. For example, let's say you send me a copy of the source (in one huge file), and I want to change something. 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. Sorry to get religious on you ... :-) -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) (01/14/91)
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..?'