Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Tue, 05 Apr 2011 01:42:23 -0600
"Tor Lillqvist" <tlillqvist@novell.com>
wrote:

Now, assume thre are old foo.dll and libfoo.dll.a files around, but
foo.c has been edited. If Make would cache stat calls, it would not
have any reason to believe that libfoo.dll.a indeed got updated, too,
when foo.dll was produced by its recipe, would it? So it would run
the recipe once more.

GNU make needs to rebuild everything depending on a file, if that file
has been rebuild, regardless of timestamps. If any of the direct or
indirect dependencies of a file are newer it will be rebuild. Other
wise it would be a build-order only dependency (with :| ).


Well, yeah, Make could reasonably assume that the command does indeed
update both foo.dll and libfoo.dll.a as both are targets of the
command and the recipe didn't contain $@. Or something like that. One
probably can easily come up with more heuristics that could be added
to (GNU) Make and make it better in our case. But if we start using a
modified Make, we are back where we started, with our own Make.

No, GNU make considers a target outdated, if the rule of any of its
dependencies fired, regardless if that actually changes any timestamps.
You can see that already pretty well using "make --debug=b".

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen

Attachment: signature.asc
Description: PGP signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.