On Wed, 14 Feb 2018 20:26:01 +0100, Christof Warlich said:
record the build's dependencies. On subsequent runs of the build, these depencencies could then be used to decide which compoments must be rebuilt due to changed dependencies.
Doesn't "make" already do what you want? Oh, wait...
dependency recording, because the "results" of running "ls -l" do depend on its shared libraries!
This way lies madness - touch glibc or other package like that, and you just forced a rebuild of the entire world. In fact, I suspect that trying to follow "dependencies" to that level will result in build times close to what a 'make world' would do, because computing what ends up being the transitive closure of all file references is painful. Hint: To really do this correctly, you need to be able to force 100% code path coverage - otherwise you won't pick up the fact that /usr/lib64/libsnark.so is only actually used in an error path or similar rare-access corner case. For bonus points: openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_TIME", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3 Which file(s) count? How do you test for all values of $LANG and the various LC_* environment variables? There's a reason that most sane software builds and tools like rpm / dpkg and so on just check "glibc is still version 2.22" and don't bother going any further than that. And it just gets worse if you include kernel patches - how many modules end up involved in an open() call on a USB device? How do you detect that your code "depends" on a given behavior - often kernel patches address error conditions that doesn't change the perceived behavior in your userspace program... ... until a rare error condition arises. At this point, you need 100% code coverage of both the userspace *and* the kernel. To quote the movie Animal House: "My advice to you is to start drinking heavily....."