Thanks Andersson for the comprehensive analysis.

I’d like to echo some of them.

> From what I understand the problem is that all cmake cache variables needs to be passed explicitly to all the source files.

This is one of the problems I’d like to see it solved as well.

The compile definitions of configurations are scattered around the different libraries now.

Sometimes you would have to link a library only for the compile definitions of it while they may not have any obvious dependencies.

Sometimes a library would get a compile definition by implicit linking (the inheritance of CMake).

And when you would like to add a new configuration, it could be hard to find a proper library to add the compile definition.

Centralizing all the compile definitions/configurations should solve this.

It could be either a new dedicated CMake target that collects all the definitions or a header file.

Obviously the header file wins.

> A simple approach to this would be to generate the header file from the cmake cache variables and provide this as input to all source files

This is what I had in my mind. It IS a big improvement as it solves the above issue without introducing another tool.

And it does not introduce the synchronization issue.

Best Regards,

Kevin

From: Andersson, Joakim via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, August 10, 2022 7:23 PM
To: Anton Komlev <Anton.Komlev@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

> I once created a Kconfig PoC for TF-M build system. It was a challenge to develop and maintain it, to resolve the dependencies here and there. It also required special workaround (cost) to integrate Kconfig and CMake together.

Yes, there are some challenges and workarounds needed to integrate Kconfig and CMake together. I’m aware of this. I was involved in the first prototype of the zephyr projects cmake build system where we integrated Kconfig and Cmake together from their initial Makefile build system.
But we have made a system that works, and now in zephyr we have duplicated a lot of the TF-M build configurations in Kconfig to provide this to the TF-M build system as CMake variables.

> One of the motivations was to reduce barriers for TF-M integration as config headers are very common and compatible with almost all build systems and IDEs.

KConfig can be attractive in cases where already applied but in general is an additional tool with efforts for study and maintenance as David mentioned. I think that going this route, we should make TF-M configuration be KConfig friendly to allow adding it on top, but TF-M itself should not rely on it. @Andersson, Joakim, do you think it is possible?

I understand the hesitation to include a new build tool into the TF-M build system so instead of going directly into that topic let us first agree on what the challenges are in the TF-M build system that we want to solve.

From what I understand the problem is that all cmake cache variables needs to be passed explicitly to all the source files.
This causes a lot of extra code to have to be written to pass a build flag from the cmake variable to a build define.
In addition, this is error prone because you need to provide it to the correct libraries, and suddenly there is a library that is not passed the correct build define, and we end up with a partially included feature.

My concern about the header file approach is how this file is generated and made.
In TF-M the configuration is used for 2 things: cmake build control, and compile time definitions.
The challenge is in making sure that these are in sync.

If the idea is to allow a configuration header file for compile time definitions and keep cmake cache variables for cmake build control, then I don’t see this as an improvement since the sync problem is still there.
In my opinion there should be a single configuration definition that provides the input to both systems, providing the same configuration for both build control and build definitions.

A simple approach to this would be to generate the header file from the cmake cache variables and provide this as input to all source files.
That would not be that much different from today’s solution but would simplify the maintenance of the build definitions in the build system.

Another approach would be the other way around, the header file is read as input to cmake for build control, and all source files is provided the header.
This approach could also be used as a hybrid solution where an external system runs Kconfig to generate this header as input to the TF-M build system.

In zephyr the system is to run Kconfig to generate the configuration files. Then this is read into both cmake as cache variables and provided as input to all source files through a single configuration header using `-imacros`.

TL;DR: Build control and build defines should have a common configuration.

-Joakim

From: Anton Komlev <Anton.Komlev@arm.com>
Sent: onsdag 10. august 2022 12:36
To: tf-m@lists.trustedfirmware.org; Andersson, Joakim <Joakim.Andersson@nordicsemi.no>
Cc: nd <nd@arm.com>
Subject: RE: What do you think using configuration headers in TF-M ?

One of the motivations was to reduce barriers for TF-M integration as config headers are very common and compatible with almost all build systems and IDEs.

Preliminary looks like we all see the config headers as a good move in general while implementation can vary and needs more thinking.

Can propose a hybrid model where most options are set in header files explicitly while some be generated by CMake. Probably we need a hierarchical set of config headers, similar to CMake used now.

It’s a vacation season and let’s give more time for opinions and feedback.

Thanks,

Anton

From: David Hu via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, August 10, 2022 8:37 AM
To: Ken Liu <Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

It looks like we all agree to header-file-style configuration, with some questions about the implementation.

Kconfig provides an easy-to-use configuration GUI for make-based build system. I’m not sure if it is worth setting up another complex configuration system, besides existing CMake one, just to generate C header file.

I once created a Kconfig PoC for TF-M build system. It was a challenge to develop and maintain it, to resolve the dependencies here and there. It also required special workaround (cost) to integrate Kconfig and CMake together.

IMHO, a lightweight implementation to generate/parse the C header file(s) for configuration can be more flexible.

Best regards,

Hu Ziji

From: Ken Liu via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, August 10, 2022 2:03 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

For the first bullet:

- Configuration header files are a must, it is a common result for various project systems.

- Configuration switch is a project-system-specific item. Currently, we can provide a CMAKE config list for other CMAKE-based projects' convenience. For project systems other than CMAKE, we may need to use CMAKE export functionality or ask the user to add exporting support to export the CMAKE configurations into their project system file. At the current stage, start with CMAKE is a good choice.

/Ken

From: Kevin Peng via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, August 10, 2022 11:20 AM
To: Andersson, Joakim <Joakim.Andersson@nordicsemi.no>; Andrej Butok <andrey.butok@nxp.com>; Anton Komlev <Anton.Komlev@arm.com>
Cc: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

I think we have two topics here:

What’s the preferred results of configuration, configuration header file or compile definitions.
How to do the configuration.

By “configuration” I’m referring to the process of users selecting certain build configurations such as the isolation level and what Secure Partitions to build.

For the results of configurations, seems configuration header file is the preferred one.

On the configuration part (producing the result), there might be multiple options, for example sticking to CMake or introducing another tool.

Best Regards,

Kevin

From: Andersson, Joakim via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, August 9, 2022 11:04 PM
To: Andrej Butok <andrey.butok@nxp.com>; Anton Komlev <Anton.Komlev@arm.com>
Cc: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

Hi. Anton.

How would this header file be supplied to the TF-M build system?
If we are talking about simply providing a single header file to the build system and leaving the generation of this header file up to the application user I don’t think this is an improvement upon Cmake cache variables.

Someone did already bring up using Kconfig in an earlier TF-M tech forum conversation.
I think introducing Kconfig as the configuration system into TF-M would be a better approach, and this is something we already have experience with in working with the zephyr project.

The Kconfig system in the end generates a header file, in zephyr we alse have support for getting the configuration macros as CMake variables for build control.

If this is of interest to the TF-M community I would be happy to contribute to a prototype and possible implementation of this solution.

-Joakim

From: Andrej Butok via TF-M <tf-m@lists.trustedfirmware.org>
Sent: tirsdag 9. august 2022 15:32
To: Anton Komlev <Anton.Komlev@arm.com>
Cc: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: What do you think using configuration headers in TF-M ?

Hi Anton,

The proposal to “Configure TF-M via definitions in header files while leave CMake for a building control only” is highly wanted from very beginning, it can save a lot of time for us.

Thank you,

Andrej Butok

From: Anton Komlev via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, August 9, 2022 3:22 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] What do you think using configuration headers in TF-M ?

Hello,

TF-M has many options to configure. All of them are declared as a CMake variables and many of them translated to compiler definitions later.

Since the idea of TF-M configuration via config header file(s) was warmly received on the last tech forum I would like to check with community opinion on such hypothetical move: Configure TF-M via definitions in header files while leave CMake for a building control only.

Please share your thoughts, opinions and the possible dependencies.

Thanks,

Anton