On Fri, Nov 03, 2017 at 13:40:27 +0100, Guillaume Maudoux (Layus) wrote: > * Detecting changes via file hashes is always the right thing. > o Well, tup depends on timestamps to detect changes in the > filesystem, then propagates changes (independently of the > generated timestamps. If you are using the file monitor, then > tup detects any update to the files, not only a timestamp change. > o But yes, detecting changes based on hashes seems quite right, so > how is this a fallacy ? In fact, I would like tup to do this > instaed of using timestamps. > * Detecting changes via file hashes is never the right thing. > o Huh ?! This guy rants about everything... See above anyway.
You may need to rerun a rule due to permission changes on an input; its content hash is not different in this case. These bullet points basically say "you can't be perfect with only file hashes, but you also can't be perfect without them". > * People will only want to build software on Windows. > (Thanks to David MacIver for spotting this omission.) > o Ditto. This looks like a way to increase this list length. And > he seriously needed someone else to find this one... This guy > seems to lack imagination ;-). The point of these lists is to gather a list of things that one might assume about the "how to write a buildsystem" problem. Honestly, I'd be surprised for anyone to not miss some bullet points of this particular problem. > * Nobody will want to build on a system without |strace| or some > equivalent. > o Well, the less features you have on the system, the less > features you can implement in the build system. To work > properly, tup needs at leas a way to trace file accesses. This > is done using fuse file systems, and there is an implementation > usinf LD_PRELOAD. An implementation using strace exists but was > deemed too slow. > o But anyway, what is this rant about ? You're taking this too defensively. All useful build systems will handle the majority of these bullet points. > * |stat| is slow on modern filesystems. > o Huh ?! Well, okay, if this is a fallacy it means that stat is > not slow on modern file systems. How does this relate to build > systems ? Some tools aim to minimize the number of `stat` calls. These have been seen to be slow. They are slow with network and cluster filesystems even today. > o Tup uses an algorithm whose asymptotic complexity is much better > than make, who looks at all the files in the filesystem. Doing > so is simply more powerful than reading all the files. Tup may > need to stat all the files to detect changes when you are not > using the monitor. In that case, it does not distrust stat ;-). > I am using tup on firefox, and stat'ing all the files for > changes was never slow. You've never built software on a cluster filesystem from a login node which is (understandably) highly pessimized for disk access versus the compute nodes, have you? > * Said language should be based on textual expansion. > o No recent build systems does that (okay, this was written in > 2012, but still). Really, no-one does that. This point seems to be aimed at CMake and m4. And although they both do predate the list by a longshot, I'd still call them relevant today. > * System libraries and globally-installed tools never change. > o This is out of scope for a build system, this is handled by > package managers. Nix handles that very well. A build system > describes how to build. If this changes, then it needs to be > updated. There will always be system library changes that > require an update to the build description. Not all build systems add edges for system files in use. This means that they may not pick up on updated system headers. Whether this is an incorrect build or not probably depends on the system, but I'd lean towards it being an incorrect build. > * It's totally OK to spend over four hours calculating how much of a > 25-minute build you should do. > o No, it is not. The core idea of tup is to make this as fast as > possible. See the paper from Mike Shal, and the benchmarks on > the website. As I said above, not all of these bullet points make sense for all systems, but I'd bet the author has seen this behavior. > * Files only ever get updated with timestamps by a single machine. > o Change detection based on timestamps is a bit outdated, and this > is one of the reasons why it does not work well. As above, sometimes file *metadata* matters too. mtime is the only feasible way to detect those changes. > * Version control systems will always update the timestamp on a file. > o Tup requires that indeed, unless the monitor is used. Some VCS tools would set modification times based on the last-commit which touched that file. Git is sensible here. > * Version control systems will never update the timestamp on a file. > o Tup also requires to not update the timestamp of unchanged > files. It will rebuild anything that depends on files with a > modified timestamp, even if the file is the same. Depending on > your point of view, this may be exactly what you want. Compiler caches are intended to handle the "VCS touched, but did not modify a file". --Ben -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
