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. {F65944} {C123}

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}

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. {F65944}{F66009} {C123}