This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: copying a timestamp
On 11/20/2010 04:00 PM, Ralf Wildenhues wrote:
> The reply from Paul is still mostly correct though: make walks the
> complete dependency tree down and then back up. When walking back up,
> the mechanism you desire is easily implemented in a small shell command
> (as shown in the example of Paul's reply).
It's dependent on timestamp files which can be poked, prodded, and
otherwise convinced to do the wrong thing by the user. It's
fundamentally *not robust*, is the main issue.
> When first walking down, you just need to ensure that the graph really
> is a tree. There are (at least) two choices you can make at that time,
> and in GNU make you can implement them with arbitrary shell statements:
>
> - should T be updated if P is newer?
>
> T : $(shell if $$condition; then echo P; fi)
The problematic part is that you're scattering bogus timestamp files
(P!) all over the tree. This makes it very brittle. I suppose one
could construct a special subtree of timestamps which is blown away
fresh with each invocation.... that would make it *slightly more*
robust. Not *much* more.
> - should T, if it is to be updated, be updated after P is updated
> (order-only dependency, since GNU make 3.80)?
>
> T : | $(shell if $$condition; then echo P; fi)
>
> So, in summary, I think what you want is already possible, albeit maybe
> not in a concise notation.
It's not so much the notation (although that is a problem) as the
scattering of bogus timestamp files. It is true that by introducing an
auxilliary file to represent *each* logical state, and manipulating its
timestamp by hand to be "true" or "false", you can "solve" the problem,
but this is *not robust*, because the timestamp files are exposed to
general programmer manipulation. A special timestamp subdirectory tree
would ameliorate that somewhat.
It is also, incidentally, slow, due to the heavy reliance on filesystem
access and modification, for things for which the filesystem is,
fundamentally, quite irrelevant. I suppose it could be sped up with a
mounted ramdisk for the timestamp tree, but you begin to see how
ridiculous this set of kludges is.