On Sun, 2007-04-15 at 00:04 +0200, Ramón García wrote:
> If only the result of .OUT_OF_DATE is persisent, how would one
> implement dependencies based on file content changed?
It's fairly unusual to rebuild a target based on whether the target
itself has been changed; typically a target is rebuilt based on whether
any of its prerequisites have changed.
However, you're right that using only the expanded value of .OUT_OF_DATE
as the persistent state is probably not flexible enough; I did mention a
few scenarios where that would be the case.
The idea of having persistent variables, in a generic sense, is quite
interesting. Rather than having a set value saved on a per-target
basis, any variable value could be saved and reloaded by make at the
next invocation. One purpose of this would be to keep state for
targets, but people might have other reasons to do this. There are a
couple of tricky problems:
1. Where to store them? If we do it on a per-target basis (which
is probably the simplest thing to do as it avoids
locking/overwriting/etc. issues) then it's a little messy to
abstract it to any variable. We'd also need a "global makefile"
file for persistent variable storage.
2. How to set these variables. There's really no facility in make
right now for "post-command processing". Pre-command processing
can be done in a number of ways: target-specific variables or
even expressions in the rule itself are expanded just before the
target is built. But we have no facility for expanding things
just AFTER the target is built. I'd really like to find
something that doesn't feel like a hack (obviously).
--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@xxxxxxx> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
|
