Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site enea.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!mcvax!enea!kim
From: kim@enea.UUCP (Kim Walden)
Newsgroups: net.lang.c,net.unix,net.unix-wizards
Subject: Re: make depend
Message-ID: <841@enea.UUCP>
Date: Fri, 15-Mar-85 08:32:35 EST
Article-I.D.: enea.841
Posted: Fri Mar 15 08:32:35 1985
Date-Received: Tue, 19-Mar-85 04:58:16 EST
Reply-To: kim@enea.UUCP (Kim Walden)
Distribution: net
Organization: ENEA DATA, Sweden
Lines: 71
Xref: watmath net.lang.c:4792 net.unix:3971 net.unix-wizards:12481

> From article 3517 in net.lang.c:
>
> ... [a make dependency generating tool] should be picked up
> and stuck into every UNIX in existence (picked up by vendors,
> for the benefit of their licensees), because the absence of
> (semi-)automated dependency generators is a nuisance.
> People don't keep their dependency lists up to date, things
> don't get remade when a header changes, and all sorts of bugs
> crop up.  Or, worse, they only appear when ".o" files are removed
> and the modules are recompiled, so the bug appears rather distant
> in time from the actual change to the header file.
> -- 
> 	Guy Harris
> 	{seismo,ihnp4,allegra}!rlgvax!guy


I agree entirely with Guy concerning the importance of automated
dependeny generators.

There seems to be an abundance of such generators spreading around,
ranging from simplistic sed scripts to more ambitious work, but the
generators I have seen, including the ones from Berkeley, Stanford and
AT & T, are all wrong. The reason for this is quite fundamental.

Scanning source files recursively to find out exactly what files will be
included in what other files, which lately seems to have been added
as an extra option to the C compiler, simply does not work.

In many cases, files include other files, which are not source files,
e.g. the typical #include "scanner.c" in a yacc program.
Such files may not be present at the time of dependency generation,
or if they are, the may be obsolete, and thus leave out dependencies
or introduce faulty ones.

One cannot force them to be up to date either, since this would require
running make, but make cannot run properly before its dependencies
have all been generated. Thus we have an inevitable hen-and-egg situation.

The solution is to use ONLY source files as a basis for
dependency generation.

I have described this at some length in the article "Automatic Generation
of Make Dependencies", Software Practice & Experience, vol. 14(6),
pp. 575-585, June 1984, and I will talk about it on the EUUG Usenix
Conference in Paris, April 1-3.

When standard make suffix conventions are used (renaming files like
y.tab.c and lex.yy.c to get the base file name of the respective input
files etc.), simple transformation rules can be used to deduce from
the source file names and include statements extracted from them just
what include statements will be present in the generated files,
without actually creating these.

This also has the advantage of being easily parameterized to handle
include mechanisms in other languages than C.

I have a program that takes a complete set of source files,
extracts all include statements from them, and generates the
correct set of dependencies using a set of default suffix
transformation rules, without requiring any generated files to
be present.

If Berkeley is interested, I would be willing to include it as
user contributed software to bsd4.3.
-- 
	Kim Walden
	ENEA DATA Sweden

	UUCP:	{seismo,decvax,philabs}!{mcvax,ukc,unido}!enea!kim
	ARPA:	decvax!mcvax!enea!kim@berkeley.arpa
		mcvax!enea!kim@seismo.arpa