make depend

Kim Walden kim at enea.UUCP
Thu Apr 11 00:11:51 AEST 1985


In article <9201 at rtp47.UUCP> throop at rtp47.UUCP (Wayne Throop) writes:
>> ...
>> The solution is to use ONLY source files as a basis for
>> dependency generation.
>>  ...
>>     Kim Walden

> Kim's solution seems quite good given the way make works.  If you are
> willing to change make's model of the world, another solution becomes
> available.  In particular, if a make-like tool allowed dependencies to
> be specified dynamically, the problem of intermediate files being needed
> before make is invoked (to allow dependencies to be discovered) becomes
> a non-problem.
> 
> There are many ways for make to be modified to allow for dynamic inputs,
> but suppose a syntax something like
> 
>     foo.o: foo.c (foo.c; find_includes foo.c)
>             cc -c foo.c
>     foo.c: foo.x
>             make_c_from_x foo.x
> 
> The parenthesized text specifies a list of inputs to the "command"
> at the end of the list.  The output of the command will be a list of
> include files, and the effect is as though that list of files had been
> supplied instead of the parenthesized text.  What make would do for
> this makefile fragment would be to invoke make_c_from_x, then invoke
> find_includes (discovering any include file dependencies of foo.c),
> and then cc foo.c, producing foo.o.
> 
> ...

I do not agree with your proposal, because:

	1. Very few people really understand the implications
	   of make's basic model as it is, so the least thing
	   we would want to do is to complicate it further.

	2. It would not solve the problem anyway.

	   In the example, make itself forces the generated file foo.c
	   up-to-date before invoking a command to extract include lines
	   from it.
	   But an extraction command will have to deal with nested includes,
	   and when an INCLUDED file is a generated file, the command cannot
	   force it up-to-date, and hence cannot proceed to search the
	   file for more include lines.

	   The hen-and-egg syndrome is still there, and cannot be
	   circumvented.

-- 
	Kim Walden
	ENEA DATA Sweden

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



More information about the Comp.lang.c mailing list