On Mon, 22 May 2000, Mike Hopkirk(hops) wrote:
> On Mon May 22,2000 (01:24:19PM +0200), broeker@... Broeker) wrote:
> > Among the things that become easier with such a modularised source, one
> > would be replacement/improvement of the user interface, and generally any
> > kind of work on extending the sources.
> How so ?
> At some stage you still need to change the header invocations in the
> clients of the modules or force a recompilation.
Of course. Once, someone (me) would have to go over all source files, and
replace #include "global.h" by a selection of exactly those #include files
needed by that particular source file. That's a one-time operation, like
the whole splitting would be.
> Its no more difficult to do that through a change in a global header
> than changes in separate module headers.
Wrong, at least for a properly designed interface between the individual
modules. In a somewhat idealized world, you would be able to replace the
sources implementing, say, the user interface, by a completely rewritten
version, just like that. The interface (contained in the header) wouldn't
change. Or, *if* you change the header (add some functions, or remove a
global variable, whatever), only those other modules that do depend on
particulariaties of the previous implementation would have to be
> > Currently, whenever you add a
> > function, you add it to global.h, forcing a recompile of the whole program
> > through dependency rules, even though you only changed one or two source
> > files, effectively.
> We're talking about 20 odd source files,
> building the whole thing takes < 30 seconds
Right. And during my work on the program so far, I'm sure I've had to wait
for those 30 seconds at least a hundred times or so, as each change
required a complete recompilation of the whole thing, even if I only
changed the return type of a single function contained in global.h.
> > After all, there is some reason why there is not just a single '#include
> > <ansilib.h>' in the C language description, but a whole collection of
> > separate headers.
> scale - the std lib srcs sources are something like 1.2 MB in 430 files
We're not all that far away from those figures, already. Libc sources have
roughly one function per source file. global.h currently has about 90
function prototypes inside, already. The total cscope source code size is
0.3 MB. I.e. we're less than order of magnitude away from libc.
> How many headers are you talking about replacing global.h ?
Don't know. I haven't analysed interdependencies enough to see a good
module layout through the layers of mist, yet.
> > This makes it harder than necessary to work on an isolated part
> > of the machinery without disturbing operation of almost completely
> > unrelated ones.
> How so ?
> If you're changing API's you have to change the calls anyway - if the pieces
> are totally unrelated they unaffected by the change whether the prototypes are
> in a single file or unrelated.
Sure. But the compiler cannot see that, i.e. you're forcing more work on
the compiler than necessary.
> Being in a single file they force a
> recompilation/prototype check regardless of whether you have the
> correct file inclusion combination or not ...
It's of course necessary to make sure that headers needed by some module
are included by it. But that's quite easy to guarantee, with a usable
compiler's warning levels turned on. It will immediately complain about
any missing prototype by a warning message.
> > Not unintelligible, but it's growing unmaintainable. Sorting function
> > prototypes by return type is ridiculous, IMHO. They should be sorted by
> > what they are doing, i.e. module-wise.
> That can be done equally well within global.h
It can. But global.h is long enough to be hard to navigate in. It'd be
easier to find the correct place for a modification in a header file if
the name of the file could be used as a first approximation. I.e. if
you're changing some externally visible detail in scanner.l, a 'scanner.h'
would be the obvious place to do the change.
> > As to problems this is already causing now, I already described one: a
> > compiler warning from compilation of egrep.y, caused by the totally
> > unrelated prototype for the yylex() in scanner.l being visible to egrep.y,
> > through global.h.
> THats more a consequence of the design of lex (not generating source and
> interface file), its assumption of a single use of a lexer in a program and
> possibly a misguided decision to put yylex proto in global.h
Well said. So: where else if not global.h would such a prototype for
yylex() go, then, in the current design? You'll notice that there is no
other sensible place, currently. That's exactly the problem with a single
'global' header file: there can be things that should be exported from one
module to some of the others, but *not* all of them.
Some old hands among the C programmers' community would write extern
declarations into the source files using the exported yylex(), in that
situation, but that's even worse than the overly strict
one-header-per-source rule would be: you'ld lose the one useful property
of prototype declarations: compile-time type checking of function
Having a bit of philosophical education, the situation strikes me as kind
of a paradoxon. A big part of the goal of 'cscope', as I see it, is that
it lets you work on sources kept in (what several experts, and myself
consider to be) a bad programming style at least somewhat coherently. I.e.
the programming style changes I propose seem to fight against some of the
reasons for which cscope exists. Moreover I'm using cscope on its own
sources to carry out those programming style improvements that would
ultimate remove the need for that very tool.
IOW, as long as you're using cscope, the changes I propose might not seem
necessary. But not everybody may want or be allowed to use cscope. This
means we could claim that coding style considerations useful or even
strictly necessary for other programs may not be needed for the sources of
cscope itself, as anybody working on the cscope sources will of course
have cscope installed and would be using it on itself.
If that turns out to be the majority position of this development team,
I'll bow, reluctantly. You may expect a "Didn't I tell you?" remark from
me, from time to time, then.
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.