Robert Collins wrote:
-------------------
> On Sun, 2004-01-04 at 08:17, Laurence Finston wrote:
>
> > The problem is that make makes certain assumptions that don't apply when
CWEB
> > is used.
>
> I think thats an incorrect statement. It would be more accurate to say
> that CWEB hasn't been built with any thought to the impact on make. Make
> has only the file system data available to it to determine 'has X
> changed more recently than Y.' config.status for example, when it
> regenerates config.h will only alter the file if the contents have
> changed - so that it preserves the timestamp. I think that most
> pre-preocessors in this sense could benefit from a wrapper of some sort
> that would equally not alter the file IF nothing had changed - and you
> could use that wrapper directly in make rules for ctangle.
>
> Rob
>
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
However, this didn't work, because some of the default rules automatically
generated by Automake expected rules involving the C++ files generated by
ctangle; ones for building the object files, I believe.
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.
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 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.
I plan to start working on implementing an input routine using Bison and Flex.
Once 3DLDF has one, the executable won't have to be built over and over again.
However, this will continue to be necessary for users for a couple of months,
at least, and it will always be necessary for developers. I don't know yet how
I'm going to solve the problem of rewriting the build rules in Makefile.am to
account for the Flex and Bison files.
The original pre-GNU distribution of 3DLDF didn't use Autoconf and Automake
and I was able to solve the problem of expressing the dependencies among the
files. It's not even a difficult problem to solve, when you don't have to use
make. RMS wanted 3DLDF to have a configure script and Makefile.in files with
all of the required targets and I thought that was reasonable, and even
desirable. However, the only practical way to do this, in my opinion, is to
use Autoconf and Automake, which are great in other ways. However, I think the
problem of expressing dependencies is a serious one.
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.
I'm not just complaining, I'd be quite willing to contribute to a solution. I
haven't even looked at the Automake sources yet, so I don't know whether I
could help by doing any programming. However, I do at least have a project
that could be used for testing any facilities the Automake developers program.
This assumes that other people also think that it's worthwhile to try to solve
this problem.
Laurence Finston
3DLDF maintainer
Website: http://wwwuser.gwdg.de/~lfinsto1
email: [EMAIL PROTECTED]
