[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 03 Jan 2004 22:17:19 +0100
IMHO/0.98.3+G (Webmail for Roxen)
When I started using Autoconf and Automake for my package, 3DLDF, I had some
problems expressing the dependencies among the files used for When I started
using Autoconf and Automake for my package, 3DLDF, I had some problems
expressing the dependencies among the files used for
building the executable.
I'd be interested to learn whether other programmers have similar problems,
and whether the Automake maintainers think that it would be worthwhile
implementing a solution within Automake. I'd be happy to contribute, if I can.
The problem is that make makes certain assumptions that don't apply when CWEB
is used. `ctangle <filename>.web' creates <filename>.c. Additional files can
also be written. In 3DLDF, each <filename>.web also writes <filename>.h. If
<filename>.web is changed, it must be ctangled, which regenerates <filename>.c
and <filename>.h, thereby updating their timestamps. However, not all changes
to a .web file cause the .c or .h file to differ from its previous version,
while make assumes that a target file must be rebuilt if one of its
prerequisites is newer.
I've worked around this problem by using a shell script and two empty "timer"
files for each set of <filename> files. However, if neither the .c nor the .h
file has changed since the previous version, the .web file must be touched to
an earlier time, using `touch --reference'. This makes it necessary to revert
its buffer in Emacs, because it changes the file on disk. I assume that other
editors will behave similarly.
This situation arises when only the TeX text in the .web file has changed. It
is harmless, but quite annoying, and may bother users. I don't think there's a
way around it, because `ctangle' must be called if the .web file has changed.
It doesn't work to use a third timer file, because ultimately, the timestamp
of the .web file must be tested.
I recently tried to have a .web file write an additional file with a different
filename containing a template definition. The latter file was meant to be
included in some files, but not all of the ones that include the .h file
generated by that .web file. I was unable to write rules in Makefile.am to get
this to work. In the end, I put the template definition into its own .web
file, and it's written to an .h file with the same name. In other words, I'm
using the mechanism that already works. I'm not happy about this, because it
means the vagaries of make are forcing me to structure my package in a
particular way; and not the best way, in my opinion.
3DLDF is a GNU package, so it must have all the required make targets. In
practice, this means I must use Autoconf and Automake.
Before 3DLDF was dubbed a GNU package, I used an auxiliary program for
controlling rebuilding. It uses two bitsets: one for expressing dependencies
and one for keeping track of which files have changed. I originally tried to
get make to use it for rebuilding 3DLDF, but the default rules generated by
Automake required valid rules for building the C++ and object files, which
made the auxiliary file redundant. I've removed it from the distribution, but
I still use it myself sometimes. I may put it back in, because it works
without changing timestamps, so it's never necessary to revert buffers.
I think it might be worthwhile to implement a general mechanism for expressing
dependencies in Automake, similar to my auxiliary program. It could be
programmed in C using bit-fields rather than in C++ using bitsets, if