--interactive does not clean cache signatures
This issue was originally created at: 2010-04-05 15:45:32.
This issue was reported by: bgagnon.
bgagnon said at 2010-04-05 15:45:33
I am getting weird behavior with CacheDir and interactive mode. Consider this:
# SConstruct
SetOption('implicit_cache', True)
CacheDir('/tmp/sconscache')
Program('foo', 'main.cc')
/* main.cc */
#include "main.h"
int main(int, char**) {
foo x;
return 0;
}
/* main.h */
struct foo {
int a;
};
Initial build:
rm -rf /tmp/sconscache
rm -f .sconsign.dlite
scons -Q .
>> g++ -o main.o -c main.cc
>> g++ -o foo main.o
Enter interactive mode:
scons -Q --interactive
scons>>> b .
scons: `.' is up to date.
Open another shell, modify main.h:
/* main.h */
struct foo {
int a;
int b;
};
Build again:
scons>>> b .
g++ -o main.o -c main.cc
Modify main.h again:
/* main.h */
struct foo {
int a;
int b;
int c;
};
Build again:
scons>> b .
Retrieved `main.o' from cache
Which is wrong, because main.o was never built with that content of main.h.
As an added proof, modify main.h again:
/* main.h */
struct foo {
syntax_error(
};
Then build:
scons>>> b .
Retrieved `main.o' from cache
The build should have failed at this point, since no cache hit is possible. My conclusion is that main.o was correctly identified as being out of date, but the cache signature it used was not updated/cleaned properly.
gregnoel said at 2010-04-30 17:37:01
Bug party triage.
Are there any updates on this issue? Thanks!
@benkwa - Any updates would be above.. so if you don't see any, then likely there aren't any updates. If you want to ping the community as a whole to cajole/encourage/pay someone to work on it, then I suggest shooting an email to the scons users mailing list.
That would be more effective as there are way more subscribers to the mailing list than there are to this bug and/or all scons bugs.
I tried this, it works as noted if you don't leave scons, while if you do leave scons if behaves as expected (that is, rebuilds again).
There's logic in interactive to clear some things,
# Clean up so that we can perform the next build correctly.
Perhaps missing logic relating to caching?