This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: copying a timestamp (Was: Ping^2: RFA (build): Avoid circular dependency)
On 11/14/2010 09:46 AM, Joern Rennecke wrote:
> Quoting Joern Rennecke <amylaar@spamcop.net>:
>
>> P.S.: Of course it's the other way round:
>> doc/tm.texi depends on the stampfile,
> Oops, there is the circular dependency again.
>
> What we actually need is a timestamp that says that the consistency has
> been
> checked, and which depends on doc/tm.texi - that's our current s-tm-texi -
> plus a generated file that depends on s-tm-texi, but bears the file system
> time stamp of doc/tm.texi .
> I.e. the s-tm-texi rule should make this file.
> Can we use cp -p for this portably?
> In principle we could also use some combination of time and ls and shell
> substitutions, that would use less disk space, but I fear the portability
> issues there could be worse.
Just in case anyone's looking for a good project, I figured out a VERY
long time ago that the true long-term solution to practically all
problems I've ever encountered in Makefile design, including this one,
lies in creating an extension to "make". Unfortunately I've never
gotten around to digging into the internals of anyone's version of
'make' in order to figure out where to implement this, and the GNU make
people were completely uninterested, since they didn't get why it was a
good idea.
'make' badly needs a mechanism whereby the Makefile programmer can
specify a code fragment for a given target A which answers the question
'is A up to date?'. The default implementation would be to check the
timestamp relative to the timestamps of the dependencies, but the
Makefile programmer should *be able to specify arbitrary rules*. One
would want them to be fast, but that's the Makefile programmer's
problem. :-) They should be able to depend on the boolean answers to
the question of whether the prereqs are up to date.
It would be easier to do this in make than by the generation of many
artificial, breakage-prone timestamping and phony targets; it would also
render the majority of GNU make extensions irrelevant.
In the meantime, Joern's patch of 2010-11-14 looks good to me.