[Scons-users] Scanner / Builder Race Condition?

[Brian Cody]

Hey folks,

We have a command builder that creates a file, let's call it project.prj.
The project.prj file is a '.prj' file, which we have a scanner for.

create_project_target = env.Command(project_prj, [project_file_sources],
create_project_function)

Then I have two builds that take it as a source:

version_file = env.GenerateVersionFile(bin_file_name, create_project_target)
binary = env.Compile(bin_file_name, [create_project_target, version_file])

If the project.prj doesn't already exist, everything works as expected. The
prj file gets created and then scanned, and then the builds proceed.

The problem is when I change a file in project_file_sources. SCons will
invoke the scanner on the project.prj file before it runs any build. That's
OK, it's just a potential waste of time. The problem is that (with multiple
jobs) it will start running re-building the project.prj file, and before
waiting for it to be done, it'll start scanning the file again! The scanner
will now throw an exception.

Simplified log:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Start Scanning
Done Scanning
scons: rebuilding `project.prj' because `project_prj_source' changed
create_project_function(["project.prj"], [project_prj_source_list])
start of create_project_function
Start Scanning
PRJ SCANNER EXPLODE!!! <--- helpful try/except block
end of create_project_function
scons: *** [bin_file_name] IndexError : list index out of range <--- The
exact error varies, it's just what happens when the file you're scanning is
suddenly truncated.

I would rather not disable the multiple jobs, and multiple invocations of
SCons really isn't acceptable either. Is there any proper way to get SCons
to wait to scan a file that it has already determined needs to be rebuilt?

Also if we perform an Execute(Delete(project_prj)) at the top of the
SConstruct it "works", however due to how our version file works it will
always perform the build of the bin_file_name. This is extremely costly in
this case! (It's a Xilinx build).

Thank you!
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160222/ecfa57fb/attachment-0001.html>