From: Markus Scherschanski (mscherschanski_at_[hidden])
Date: 2002-06-06 02:42:16
> If you can keep track of everything that gets built *and* you
> have access
> to something which can modify the files' mod. time, *and* you
> don't mind
> inaccurate but consistent mod. times, you can change the mod
> time of any
> target that still has the same or earlier time as any of its
> sources after
> its build action completes.
> It's a bit of a hack, but I think it should work for
> real-world builds.
Okay, that would be a solution, but it fails when those files are copied
between FAT and NTFS, doesn't it?
> > > I don't see any way to detect false matches without going to
> > > some scheme
> > > that avoids timestamps completely in favor of using the real file
> > > contents.
> > Yeah, that would be good, MD5 or CRC32?! ;)
> > But that would be rather slow and not secure in some
> unfortune cases.
> Yeah, I would rather do the mod-time hack above and only use
> MD5 as a last
> resort when we really think the file needs updating, because
> my impression
> is that it would be faster.
But you even have always to build all MD5-sums even for those cases.
> I'm not sure there's a real security problem, but SK can say
> better than I.
With this algorithms there is always a rest probability that two files have
the same checksum even when they differ. This prop is with MD5 at 1:2^64
(rather small) but not impossible.
> However, I am somewhat inclined to leave this sort of rebuild-accuracy
> concern to Scons, and to concentrate on higher-level build
> architecture for Boost.Build.
But basics have to be okay too. I heard several times about this problem.
I think this is how someone in GNU-Make solves the problem:
> A conservative scheme which treats targets as outdated if the
> sources were modified within the accuracy window is probably
> good enough for us, for the time being.
Okay for me, but I'm not sure at all. Steven?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk