When code changes are made today, the accuracy and completeness of the list of impacted components that need to be rebuilt is dependent on:
a) Developer knowledge of the type of impact that result from code changes of varying types.
b) Manual scans to try to identify code that incurs the impacts identified.
The makefile variable componentname_deps provides the ability to define dependencies such that the componentname should be rebuilt if any the associated components changes. However, in many cases this is very coarse grained (e.g. if a header is defined as a dependency then any change to the header should force a rebuild of the component) and it is also totally reliant on diligent maintenance of an accurate dependency list.
If a build dependency is missed the results can be highly impactful, especially in the nefarious cases where the effects of the missed rebuild are not immediately apparent in testing and lead to corruption (core and database). Due to the importance of ensuring no build dependencies are missed, developers are likely to include rebuilds that are not strictly required rather than spend manual time and effort determining the true list of rebuilds required. This unnecessarily increases the scope of the change for the developer and the test engineer assigned to testing.
We need tooling to identify accurate build dependencies resulting from code changes. This tooling:
- would ideally be extensible to highlight changes that affect file resident data
- would ideally be extensible so that it could also assist in identifying the area of code impacted by the rebuild so that focused test cases could be created.
- could be part of a future wider suite of tooling that also provided visual insights so that developers could better understand relationships between components and therefore make informed design decisions that incorporated the scope of impact of any proposed change.
The types of build dependencies the tool would need to be able to identify includes at least:
- Changes to inline code generated by assembler macros (may only affect a subset of parameters coded)
- Changes to the size or order of members in structures (DSECTs or C structs) or objects
- Changes to the value of existing enums or equates
- Addition of a default parameter on an existing function
- Changes to inline functions/methods
- Changes in derived classes due to changes in a base class.
- Changes that affect inheritance
- Changes to the number or order of virtual functions
A build dependency implies code that needs to be rebuilt but does not need a source code change. However, the tooling should also be able to identify code that will no longer build RC=0 due to the target code change. The purpose here is to identify premature removal of enums, data members, etc., as well as code that needs a source update. The types of scenarios covered here should include:
- Referenced enum values are removed
- Referenced data members are removed
- Referenced functions or class methods are removed
- Referenced functions or class methods change their signature requiring additional or fewer parameters, or changes in parameter order or type etc
The tooling would ideally also be able to highlight unexpected impacts such as
- The size of an enum changes
The developer should be able to run the tool on request as part of the development process.
Suggested output from the tool is:
- A list of changes that create build dependencies with a list of dependent components found for each list item.
- A list of changes that will cause code to fail to build with a list of the impacted components for each list item.
It would be a “nice to have” if the tooling could identify the name of the dependent/impacted SO as well as the dependent/impacted component (source file).
Note: Category given as "Other" to open up option for how to provide this tooling (platform , part of TPF Toolkit or not etc).
