Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!mordor!lll-tis!lll-lcc!pyramid!weitek!aimt!breck From: breck@aimt.UUCP (Robert Breckinridge Beatie) Newsgroups: comp.software-eng Subject: Question Re: Configuration Management Keywords: configuration management, software design Message-ID: <497@aimt.UUCP> Date: 11 Feb 88 19:18:08 GMT Organization: AIM Technology, Palo Alto, CA Lines: 30 I've been having a discussion with my boss about how to re-partition the source for a small package. When we failed to convince each other to our respective points of view my boss kind of ended the argument by declaring that "in his experience" the problems with my approach outweighed the benefits. Since I don't have enough experience of my own to effectively counter such sound logic, I thought I'd ask the net. Basically the argument is over one question: "Is it acceptable to have more than one 'call interface' per source file or not?" For our purposes a 'call interface' is defined as a non-static function in a C source file. My boss' position is that having more than one 'call interface' per source file causes so many "configuration management" problems that it outweighs any benefits. Now I've never heard this recommendation before. Nor have I ever seen (non-trivial) software that only had one 'call interface' per source file. I've gone looking through the source to all our products. I've looked through some of the software from comp.sources.unix. I've also looked through libc.a and in every case there were object files with more than one extern function definition. But still, I don't have any real experience with "configuration management" so I have to ask the experts for the benefit of their experience. So how about it? What horrible CM problems does having more than one 'call interface' per source file cause? Has anyone had any such problems? I'd appreciate any horror stories, anecdotes, or opinion. -- Breck Beatie {uunet,ames!coherent}!aimt!breck "Sloppy as hell Little Father. You've embarassed me no end."