[SERVER-59614] ninja tool could fail to detect compiler changes Created: 26/Aug/21  Updated: 14/Jul/23  Resolved: 14/Jul/23

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

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

Assigned Teams:
Server Development Platform
Sprint: Dev Platform 2021-09-06, Dev Platform 2021-09-20, Dev Platform 2021-10-04, Dev Platform 2021-10-18, Dev Platform 2022-01-10, Dev Platform 2022-01-24, Dev Platform 2022-02-07, Dev Platform 2022-03-07, Dev Platform 2022-03-21
Participants:

 Description   

In SERVER-56003, Mathias discussed the issue with using mtimes for checking if the compiler has changed. There are cases where the compiler could change, and the mtime still not be newer, which is what ninja checks for when rebuilding.

Not just for compilers but any tool, or in ninja tool terms, providers, which are generally binaries not part of the source tree which are used to build nodes, for example, compilers.

A solution to this would be to hash to providers and depend on a file containing the hash, only updating the file if the hash has changed. Then via ninja's restat we can decide for sure if things should be rebuilt not just from the mtime.



 Comments   
Comment by Steve Gross [ 14/Jul/23 ]

We plan to adopt Bazel in the coming months, which will address this issue (Bazel has sufficient dependency analysis for stuff like compiler-changed).

Comment by Iryna Zhuravlova [ 24/Mar/22 ]

We are pushing this back to the backlog. We will revisit this when we have more bandwidth to work on it. 

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