Introduction ======== This document provides a summary of the new TF-A buildsystem proposal. For technical details, please check (Gerrit). Two phase approach ============== The migration of the TF-A buildsystem is a long and complex process, to make it more managable, it should be split into two phases: First phase: no code refactoring ------------------------------------- * Identify needs for the CMake framework * Create first version of the framework * Source code of TF-A is not modified * Project structure, modularization, etc. not modified In the first phase the focus is on the framework, the project source code is unchanged. Therefore the buildsystem logic will be similar to the current Makefile based. This means that not all CMake features can be used. Second phase: code refactoring ------------------------------------- * Refactor TF-A source code where necessary * Better modularization, clear APIs and dependencies * Adjust framework to changes Some parts of the TF-A source code are currently monolithic, with no clear modules and dependencies defined. In the second phase this can also be refactored, to make the project more flexible. With the better modularization, more CMake features can be used too, e.g. transitive dependency handling, etc. This also causes that some changes are necessary to the framework. {F66009}

Abstract ===== The current TF-A buildsystem became too complex and rigid, a new buildsystem using CMake is proposed. This document provides a summary about how we plan to introduce the buildsystem related changes to TF-A. For technical details, please check https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2662/ Timeline ===== The migration of the TF-A buildsystem is a long and complex process, to make it more manageable, the plan is to split to two phases: First phase: introducing cmake support ------------------------------------------- * Feasibility study and prototyping. * Create a build-system framework based on cmake. * Imlement build solution for TF-A using the framework. * No source code modification. * No project structure modification. In the first phase the focus is on the framework and the project source code is unchanged. Therefore the buildsystem logic will be similar to the current Makefile based, the full potential of CMake is not used. Second phase: refactoring ------------------------------------- * Enhancement of TF-A structure. * Source code refactoring to enhance flexibility. * Better modularization, clear APIs and dependencies * Build framework enhancements. Some parts of the TF-A source code are currently monolithic, with no clear modules and dependencies defined. In the second phase this can also be refactored, to make the project more flexible. CMake allows easy modularization (e.g. transitive dependency handling, etc...). This also causes that some changes are necessary to the framework. The following diagram describes the planned timeline: {F68687, layout=center, size=full}

IntroductionAbstract ======== The current TF-A buildsystem became too complex and rigid, a new buildsystem using CMake is proposed. This document provides a summary of the new TF-Aabout how we plan to introduce the buildsystem proposalrelated changes to TF-A. For technical details, please check (Gerrit).https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2662/ Two phase approachTimeline ============== The migration of the TF-A buildsystem is a long and complex process, to make it more manageable, it should bethe plan is to split into two phases: First phase: no code refactoringintroducing cmake support ------------------------------------------- * Identify needs for the CMake* Feasibility study and prototyping. * Create a build-system frameworkk based on cmake. * Create first version of* Imlement build solution for TF-A using the framework. * S* No source code of TF-A is not modifiedmodification. * P* No project structure, modularizification, etc. not modified. In the first phase the focus is on the framework, and the project source code is is unchanged. Therefore the buildsystem logic will be similar to the current Makefile based., This means that not allthe full potential of CMake features can beis not used. Second phase: code refactoring ------------------------------------- * Refactor* Enhancement of TF-A source code where necessarytructure. * Source code refactoring to enhance flexibility. * Better modularization, clear APIs and dependencies * Adjust* Build framework to changesenhancements. Some parts of the TF-A source code are currently monolithic, with no clear modules and dependencies defined. In the second phase this can also be be refactored, to make the project more flexible. With the better modularization, more CMake features can be used too, CMake allows easy modularization (e.g. transitive dependency handling, etc. ..). This also causes that some changes are necessary to the framework. {F66009}The following diagram describes the planned timeline: {F68687, layout=center, size=full}