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
