[SERVER-27962] Adding new error codes should not force a global recompile Created: 09/Feb/17  Updated: 28/Jul/20  Resolved: 27/Jul/20

Status: Closed
Project: Core Server
Component/s: Build, Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: Andrew Morrow (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Dev Platform 2020-08-10
Participants:

 Description   

Currently, if a new error code is added to the error_codes.err file, this causes the error_codes.h and error_codes.cpp files to be regenerated. Since these files are new, all TUs that depend on any error code are now out of date and must be recompiled.

This means that pulling master is always a risk for causing a global rebuild. It also means that the SCons cache becomes invalid, and all new objects must be populated.

It would be better if the error codes mechanism partitioned the space of errors somehow (maybe using an error space concept, or similar), such that adding new errors codes was less disruptive.

In particular, replication and sharding specific errors could be placed in designated error spaces defined in their own headers. New error codes added to those spaces would only cause recompilation of code that was interested in sharding or replication error codes. Other code would not need to be recompiled.



 Comments   
Comment by Andrew Morrow (Inactive) [ 27/Jul/20 ]

I'm closing this as won't fix. The ticket has bounced around among server teams and has now ended up with SDP, which isn't really the right team to do the work.

The options here appear to amount to either generating one header for every error code and class, or partitioning into groups like error_codes_a_to_f.hpp. Both would be annoying to use, and the latter would require a decent amount of work to do well.

The git history suggests that this file changes about 5-10 times a month. That isn't nothing, but it also isn't so severe that it is a major disruption to build throughput. Should we find in the future that the rate of change in this file increases, we can revisit the problem.

Generated at Thu Feb 08 04:16:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.