[Scons-dev] please try latest default branch

Dirk Bächle tshortik at gmx.de
Fri Jan 10 13:50:14 EST 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140110/f89fdb9a/attachment.htm>


More information about the Scons-dev mailing list