Peter Samuelson wrote:

>The way 'make' determines when a file needs to be rebuilt is by the
>simple heuristic "is this file older than any of its dependencies?"
>This works fine if you can trust your timestamps to increase
>monotonically.  Seems obvious - but there are in fact at least four
>scenarios where you *don't* have monotonic timestamps:
>
>(1) If some files are on an NFS server and others on a local machine
>(think separate source / object trees), the two system clocks may be
>far enough from each other that a freshly built object file still shows
>up as "older" than the source - or a stale object shows up as "newer".
>(2) You can get similar effects one a single box by using ntpd to skew
>your local clock.  (3) Things like 'tar', plus certain (broken) source
>management tools, can move a file's timestamp backward.  (4) Finally,
>if you use shadow trees, and you delete a file on a shadow layer - so
>that a different source file is "visible" than was visible last time
>you built the object - the "visible" timestamp is not indicative of
>whether the object is up-to-date.
>
>Keith's kbuild2.5 fixes all four problems by tracking all source file
>timestamps; it triggers an object rebuild *whenever* the source file's
>timestamp changes - whether or not the source is "newer" than the
>existing object, and whether its time moved forward or backward.
>
>Like I said, this is a feature the world has done without for the past
>15 or 20 years, so it's kind of a hard sell - unless you use shadow
>trees, where it is quite necessary because of case (4).
>
Makes sense now.

>>It's quite ironic but I bet Kai ends up with something similar to
>>kbuild-2.5 at the end of the day.
>>    
>>
>Certainly Kai has studied kbuild2.5, but there really isn't any way to
>use an incremental approach to produce the kbuild2.5 architecture from
>the in-kernel kbuild architecture.  It's a  problem of "irreducible
>complexity", as they say in evolution debates.
>
But surely, eventually it will need a rewrite if the build is to be 
"correct".  A single makefile is surely required to get know the 
complete list of dependencies.  How could this be incrementally 
introduced ???

>I hear ya.  Remember the 2.1.1xx days?  Linus looked at the relatively
>mature "uusb" project and basically said "Wow, what a load of crap, the
>usb spec isn't *nearly* this complex."  Then he spent a weekend hacking
>up an extremely simple but working usb keyboard / mouse driver.
>
>Fast-forward a few years and look at the kernel usb system now.  I have
>no idea whether it resembles "uusb" at all, but simple it ain't....
>  
>
Yes that would be interesting.

Cheers,
Brendan Simon.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel

Reply via email to