|
|
Boost Testing : |
From: Steven Knight (knight_at_[hidden])
Date: 2005-09-18 14:33:07
Hi David--
>>> shouldn't a build system notice when the compiler has changed by itself?
>>
>> How do you detect this? What you are suggesting *would* be nice, but I
>> don't see an easy way to do this, for the simple reason that you would
>> need to check all of the files in the compiler directory and add those
>> timestamps to all the files that were built...
>
> It's not out of the question. I believe Scons does that. At least it
> was part of the original design.
Not by default, although that's going to be enabled some time soon.
It's configurable.
SCons will simply treat whatever thing will get executed to build a
target as a dependency file, and the target will be out of date if that
file's contents or timestamp change (depending on which you're using).
Technically, Reece is correct that you'd *really* want to depend on all
of the supporting files as well, because of course any executable could
call any number of other commands or scripts that might affect the build.
Right now in SCons you'd have to configure that as an explicit dependency.
In SCons, though, directory trees are first-class dependency objects,
so you could literally just point your depedency to the appropriate
directory tree:
env.Depends(target, '/usr/lib/gcc/i386-redhat-linux/3.4.3')
and it would detect that the target is out of date if any file changed
anywhere underneath that tree.
In practice, I think almost nobody does this because it's relatively rare
to have a change to an underlying file that you care about that *isn't*
reflected in some change to the wrapper executable, even if it's just
a bump of a version number. So using the executable works well enough
for the vast majority of cases, and is a lot faster than MD5 summing
or fetching timestamps on an entire directory tree that's most likely
under administrator control, anyway.
--SK