Re: Expressing dependencies

[Robert Collins]

On Mon, 2004-01-05 at 03:53, Laurence Finston wrote:

> This is essentially what I tried to do by using the auxiliary program
> `3DLDFcpl' in the rule for building the executable `3dldf' (roughly):
> 
> 3dldf: $(3DLDF_CWEBS)
>        3DLDFcpl

Thats not quite what I was suggesting.

> Not changing the timestamp of the .cxx file isn't enough. In fact, I change
> the name of the ctangle output from <filename>.c to <filename>.cxx based on
> whether the file has changed since the last version, and use the .cxx file in
> the rule for building the object files. This preserves the timestamp of the
> .cxx file, if the .c file doesn't contain any significant changes.
> 
> I actually had a problem with Automake assuming that 3DLDF was a C program
> rather than a C++ program because of the .c extension. Comparing the .c files
> to the .cxx files, renaming them, if appropriate, and using the .cxx files in
> the rules for building the .o files solves this problem. I think there's at
> least one other way of solving it, perhaps by means of an Autoconf variable,
> but I don't remember off-hand. 

Right, thats orthogonal though: if we 3dldf.o is built from 3dldf.cxx
and 3dldf.h, and 3dldf.cxx and 3dldf.h are built from wdlfd.web; then we
can focus on the dependency issue - not the actual extensions.

> It's reasonable behavior for Automake to assume that the sources for a C++
> program are called <filename>.cc, <filename>.cxx, or <filename>.c++, but it is
> very restrictive to assume files need to be rebuilt based merely on the
> information that their prerequisites have a more recent timestamp. 

As I said, thats the /only/ information (cheaply) available to automake.
Alternatives include generating a md5 of the file and comparing that to
a calculated one, or other such has-content-changed tests. But make
isn't language aware - it can't tell if a file change is 'meaningful'.  

> As Andrew
> Suffield pointed out in his posting, this problem affects Bison and Flex, too,
> which are probably used much more often for GNU software than CWEB.  I suspect
> there are other tools affected by this problem as well.

Yes - and the same problem applies - make assumes that the commands it
runs are for a single purpose - with no side effects.

> I don't think the problem lies with CWEB, or Bison and Flex, for that matter. 
> CWEB isn't GNU software, and I doubt whether the authors would appreciate
> being asked to "fix" it. We can't do anything about make, either. I think the
> problem should be solved within Automake. 

The problem lies in the concept of the header 'maybe changing'. If the
header is dependent on the .web source, then it can't be considered
correct if it's timestamp is older than the .web source - because make
is meant to look at just modification dates. If you want to consider
file content changes, make has to generate some database (of sorts) to
track file content, and while we *could* do that in GNU Make, automake
targets posix make - so that would not be portable. So the rules that
will most likely work well for you are - no target to build the .h file
at all, and magic in a script to replace it if needed. Note that if the
header is replaced, you'll need to reinvoke make on the same dir, to get
it to notice that reliably.

Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part