search

SCons / scons

SCons - a software construction tool
http://scons.org
MIT License
2.11k stars 318 forks source link

Update signature file when target gets updated #2593

Open bdbaddog opened 6 years ago

bdbaddog commented 6 years ago

This issue was originally created at: 2010-03-22 03:47:26. This issue was reported by: ydirson. ydirson said at 2010-03-22 03:47:26

Currently, when a build is currently running in a tree, and one would like to run a "reporting" target on a build target that has already been built (to save time and avoid waiting until all build targets are built), running "scons -n reporting" in another term reports that all targets have to be built first, even if they have indeed already been built.

Looking at the .sconssign file, one can easily see that it has not been updated since the intermediary targets got built, which probably explains why another scons would want to rebuild things.

OTOH, I also have scons ending its job with an OSError "no such file or directory" ".sconsign.dblite", which may be linked with that update problem. Also note that this ENOENT does not seem occur with 1.0.0 - I've switched back to the lenny package and will keep you informed on that matter.

OYAH, I understand that allowing concurrent scons runs in a single tree is probably not supported at all in the general case - and that scons may instead want to yell at the inconsiderate user instead :) - the fact is, it does not seem to be yelling either.

garyo said at 2010-04-01 19:27:06

I suspect this is a dup, but the basic idea, saving the .sconsign file periodically, is excellent. Scheduled for investigation in 3.0 per bug party. However, multiple scons runs in a single tree is indeed not supported, nor will it likely work better if the .sconsign is written more often.

ydirson said at 2010-04-02 06:31:37

I understand the lack of support for simultaneous runs (although it would be more explicit by using a lock on the signature file, although that would definitely not help in my usecase ;)

However, it seems that interrupting scons also results (at least sometimes) in the signature files not being updated - at least in case of a shutdown/powerfail.

nobodyinperson commented 3 years ago

+1 for this. This would also help when interrupting a long-running SCons build via CTRL+C doesn't work and the only option is to SIGKILL the scons process (can happen due to threading weirdness in custom Python-only builders, etc...) which results in scons not writing the .sconsign file, which in turn causes scons to uselessly rebuild all of the targets in the next try as it doesn't know they were already built.

mwichmann commented 3 years ago

The topic of problems with interrupting a build also appear in #2718 and #2157 (at least)

nobodyinperson commented 3 years ago

And, this would make it possible to get a much needed total progress indication as requested in #2608 by running something like watch 'scons -n | wc -l' in a separate terminal and see the number of remaining targets decrease.

bdbaddog commented 3 years ago

And, this would make it possible to get a much needed total progress indication as requested in #2608 by running something like watch 'scons -n | wc -l' in a separate terminal and see the number of remaining targets decrease.

Have you looked at: https://scons.org/doc/production/HTML/scons-man.html#f-progress

nobodyinperson commented 3 years ago

Have you looked at: https://scons.org/doc/production/HTML/scons-man.html#f-progress

Sure. Have you looked at https://scons.org/doc/production/HTML/scons-user.html#idp140637539134736 ? 😉 (no offense)

Progress can show that something is happening, but there is still the problem, that it is not possible to determine the total amount of targets that will be built to facilitate a total progress indication as requested in #2608.

bdbaddog commented 3 years ago

Yes. I'm fully aware of it's limitations.