On 10.01.2014 18:46, Kenny, Jason L wrote:
I have the same issue with the build at my job. I thought it might
have been bug in Parts passing data around, a badly define build files
that dependson stuff differently if something exists on disk or not (
ie something that is built). However I pretty sure there is a bug in
SCons. I leaning towards bugs in way signatures are made.. honestly
this is where I go bad to needing to refactor scons. The plus side it
seems to happen for me only on one or two cases out of 90k different
outputs for the build. Parts tends to get around this when it skips
loading the Parts file that defines these nodes as for some reason the
corruption seems to happen when the build file happens, the existing
stored state seems to be correct.
Jason
Do you have Builders in your setup that create included files (like C
headers) during the run? I'm asking because the current source still has
a small problem with tools like SWIG. On the first clean run, a header
doesn't exist. So SCons finds the SWIG executable first, and then later
(during scanning) the header after it got built.
On the second run (update), the header exists already...like this, the
MD5 sums of the single implicit dependencies don't change, but their
order in the internal list of children. That's what can cause unneeded
rebuilds...it should be okay on the third run though.
You might want to try and run the build with the environment variable
"IMPLICIT_COMMAND_DEPENDENCIES" set to "False"
env['IMPLICIT_COMMAND_DEPENDENCIES'] = False
. Do the errors go away then, or get less frequently?
@Gary: Feel free to revert the mem patch anytime...we could also make it
an experimental feature, and have it activated by a special command-line
option only (for now or the next version).
Best regards,
Dirk
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
