Skip to content

Fix issue #2811 spurious rebuilds due to incorrect waiting_parents on nodes when builder has more than one target and source file generated - #3340

Merged
bdbaddog merged 13 commits into
SCons:masterfrom
bdbaddog:fix_mongo_bug_33111_multiple_targets_via_emitter_spurious_rebuilds
Apr 27, 2019
Merged

bdbaddog merged 13 commits into
SCons:masterfrom
bdbaddog:fix_mongo_bug_33111_multiple_targets_via_emitter_spurious_rebuilds

Conversation

@bdbaddog

@bdbaddog bdbaddog commented Apr 2, 2019 •

Copy link
Copy Markdown
Contributor

Fix Issue #2811

Reproducing this issue requires the following.

  1. Generated source file which outputs 2 (or more) files
  2. Action string gets scanned providing only compiler as part of implicit scan
  3. Generated file gets built. Without the bugfix only the first target's .implicit list is cleared.
  4. builder/executor/action gets tried again and implicits scanned. 2nd to Nth targets end up
    with the compiler at the beginning of the implicit list and the rest of the scanned files added to that list.
  5. That bimplicit gets saved into sconsign
  6. Second run loads sconsign, now with generated file present a regular implicit scan occurs. This yields 2nd through
    Nth target's implicit lists changing when compared to SConsign's which have been loaded.
  7. This forces rebuild of source file and this propagates to massive recompile

Contributor Checklist:

  • I have created a new test or updated the unit tests to cover the new/changed functionality.
  • I have updated master/src/CHANGES.txt directory (and read the README.txt in that directory)
  • I have updated the appropriate documentation

@bdbaddog
bdbaddog requested review from garyo and mwichmann April 26, 2019 15:25
@bdbaddog
bdbaddog marked this pull request as ready for review April 26, 2019 15:29
for parent in self.waiting_parents:
parent.implicit = None

# Handle issue where builder emits more than one target and

@garyo garyo Apr 26, 2019 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine to me. I guess my only question would be why aren't the other targets already in waiting_parents so they get cleared above? (Just curious)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a combination of the first target hit by the taskmaster walk and the fact that the N targets aren't linked. I'm going to continue looking at this, but this fix resolves a long standing issue so accepting the good enough, and then will continue working on the maybe better solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants