[SERVER-57393] Replace use of for_signature based generators with scanners Created: 03/Jun/21  Updated: 27/Oct/23  Resolved: 27/Oct/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0 Desired

Type: Improvement Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-64620 Add a SCons tool to manage export fil... Closed
Related
related to SERVER-82536 Complete TODO listed in SERVER-57393 Needs Scheduling
Assigned Teams:
Server Development Platform
Participants:

 Description   

There are several places in the codebase where we use SCons generators with meaningful for_signature handling to ensure that changes to certain sorts of files (e.g. sanitizer suppression lists or symbol export lists) cause rebuilds. We are sort of cheating though, since what we are changing with those generators is the build signature of the target, and not properly introducing a real implicit dependency.

While implementing support for forced includes in SERVER-55833, we learned of some of the downsides of this approach, and that we should instead be making proper use of Scanners to achieve this effect.

Revisit our signature based injections and figure out how to use Scanners for those purposes instead.



 Comments   
Comment by Andrew Morrow (Inactive) [ 17/Mar/22 ]

We think a way to tackle this might be to build a generic target scanner that runs a list of sub-scanners as specified in an environment variable, which can then be overridden on a per-builder call. Building that tool might make building SERVER-64620 easier.

Generated at Thu Feb 08 05:41:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.