[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. |