Hi,
This requirement could be addressed with a user specific metadata file which is processed by the build-system. Implementation wise the easiest would be to include a file like UserCfg.cmake. This file could contain set(<option> CACHE <STRING|BOOL|PATH> "") commands to set the option variables. User experience wise a text file parsed by cmake scripts would be the best. Such a file could contain variable=value lines. Longer term when Kconfig support is ready, it could cover these options too. Running Kconfig is a an act done less often, and most of the times, the user is expected to save the Kconfig input and output files. Most of the time the build-system would just use the pre-generated config. I imagine a workflow similar to the one used by the Linux Kernel.
Just my two cent's though.
/George
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu via TF-M Sent: 12 June 2020 07:33 To: Adrian Shaw Adrian.Shaw@arm.com; Raef Coles Raef.Coles@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] CMake flags
Hi Adrian,
Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
Kconfig can bring some advantages:
* It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. * Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
Best regards, Hu Ziji
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Friday, June 12, 2020 12:24 AM To: Raef Coles <Raef.Coles@arm.commailto:Raef.Coles@arm.com> Cc: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] CMake flags
Hi Raef. Thanks for the presentation today.
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
Adrian
I think I'd advocate for using a workflow of generating a cfg.cmake file from the kconfig, instead of a txt file with an associated cmake parser.
I think it'd be advantageous to not have a parser for an arbitrary config file format in the cmake, since the cmake set(CACHE) statements are already fairly user-readable. It would be different if we could only generate something less readable from the kconfig (i.e. xml/json). It would be ideal if we could generate the statements such that:
set(<variable_name> <default_option> CACHE <TYPE> "<docstring> (<valid_option> | <valid_option> | ...)"
I'm not sure if we can do this in Kconfig, but it seems plausible, and imo is the ideal solution since it gives the user of later editing the cmake config (even using a cache editor like ccmake) while documenting which choices are sane.
Raef
________________________________________ From: Gyorgy Szing Gyorgy.Szing@arm.com Sent: 12 June 2020 06:56 To: David Hu; Adrian Shaw; Raef Coles; tf-m@lists.trustedfirmware.org Cc: nd; nd Subject: RE: CMake flags
Hi,
This requirement could be addressed with a user specific metadata file which is processed by the build-system. Implementation wise the easiest would be to include a file like UserCfg.cmake. This file could contain set(<option> CACHE <STRING|BOOL|PATH> “”) commands to set the option variables. User experience wise a text file parsed by cmake scripts would be the best. Such a file could contain variable=value lines. Longer term when Kconfig support is ready, it could cover these options too. Running Kconfig is a an act done less often, and most of the times, the user is expected to save the Kconfig input and output files. Most of the time the build-system would just use the pre-generated config. I imagine a workflow similar to the one used by the Linux Kernel.
Just my two cent’s though.
/George
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu via TF-M Sent: 12 June 2020 07:33 To: Adrian Shaw Adrian.Shaw@arm.com; Raef Coles Raef.Coles@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] CMake flags
Hi Adrian,
Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
Kconfig can bring some advantages:
* It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. * Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
Best regards, Hu Ziji
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Friday, June 12, 2020 12:24 AM To: Raef Coles <Raef.Coles@arm.commailto:Raef.Coles@arm.com> Cc: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] CMake flags
Hi Raef. Thanks for the presentation today.
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
Adrian
Hi Raef,
My current prototype is to parse the options from Kconfig output file and "inject" them into CMake (by set()) in a CMake file running at the beginning of build process. Kconfig generation is an optional step before build starts, only if you request to change the configuration. Otherwise, build just starts with previous Kconfig output config as normal.
Best regards, Hu Ziji
-----Original Message----- From: Raef Coles Raef.Coles@arm.com Sent: Friday, June 12, 2020 5:34 PM To: Gyorgy Szing Gyorgy.Szing@arm.com; David Hu David.Hu@arm.com; Adrian Shaw Adrian.Shaw@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: CMake flags
I think I'd advocate for using a workflow of generating a cfg.cmake file from the kconfig, instead of a txt file with an associated cmake parser.
I think it'd be advantageous to not have a parser for an arbitrary config file format in the cmake, since the cmake set(CACHE) statements are already fairly user-readable. It would be different if we could only generate something less readable from the kconfig (i.e. xml/json). It would be ideal if we could generate the statements such that:
set(<variable_name> <default_option> CACHE <TYPE> "<docstring> (<valid_option> | <valid_option> | ...)"
I'm not sure if we can do this in Kconfig, but it seems plausible, and imo is the ideal solution since it gives the user of later editing the cmake config (even using a cache editor like ccmake) while documenting which choices are sane.
Raef
________________________________________ From: Gyorgy Szing Gyorgy.Szing@arm.com Sent: 12 June 2020 06:56 To: David Hu; Adrian Shaw; Raef Coles; tf-m@lists.trustedfirmware.org Cc: nd; nd Subject: RE: CMake flags
Hi,
This requirement could be addressed with a user specific metadata file which is processed by the build-system. Implementation wise the easiest would be to include a file like UserCfg.cmake. This file could contain set(<option> CACHE <STRING|BOOL|PATH> "") commands to set the option variables. User experience wise a text file parsed by cmake scripts would be the best. Such a file could contain variable=value lines. Longer term when Kconfig support is ready, it could cover these options too. Running Kconfig is a an act done less often, and most of the times, the user is expected to save the Kconfig input and output files. Most of the time the build-system would just use the pre-generated config. I imagine a workflow similar to the one used by the Linux Kernel.
Just my two cent's though.
/George
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu via TF-M Sent: 12 June 2020 07:33 To: Adrian Shaw Adrian.Shaw@arm.com; Raef Coles Raef.Coles@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] CMake flags
Hi Adrian,
Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
Kconfig can bring some advantages:
* It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. * Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
Best regards, Hu Ziji
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Friday, June 12, 2020 12:24 AM To: Raef Coles <Raef.Coles@arm.commailto:Raef.Coles@arm.com> Cc: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] CMake flags
Hi Raef. Thanks for the presentation today.
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
Adrian
I am sure the Zephyr Kconfig->cmake interface is able to generate cmake variables from Kconfig settings. So generating config.cmake is definitely feasible.
When config.cmake is hand written, it's ugly that you have to convert -D<foo>=bar lines to set(<foo> <bar> CACHE <type> "<description>") lines. First type is mandatory here, but -D allows CACHE entries without a type. Also the description is mandatory. These are small annoyances, but will give some additional frustration for users, and will generate additional documentation work. The custom test file solves these issues. Both solutions have pros and cons, these need to be evaluated to allow a well-made decision. I don't have a strong opinion either way, just adding some more angles to the discussion 😉
/George
-----Original Message----- From: Raef Coles Raef.Coles@arm.com Sent: 12 June 2020 11:34 To: Gyorgy Szing Gyorgy.Szing@arm.com; David Hu David.Hu@arm.com; Adrian Shaw Adrian.Shaw@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: CMake flags
I think I'd advocate for using a workflow of generating a cfg.cmake file from the kconfig, instead of a txt file with an associated cmake parser.
I think it'd be advantageous to not have a parser for an arbitrary config file format in the cmake, since the cmake set(CACHE) statements are already fairly user-readable. It would be different if we could only generate something less readable from the kconfig (i.e. xml/json). It would be ideal if we could generate the statements such that:
set(<variable_name> <default_option> CACHE <TYPE> "<docstring> (<valid_option> | <valid_option> | ...)"
I'm not sure if we can do this in Kconfig, but it seems plausible, and imo is the ideal solution since it gives the user of later editing the cmake config (even using a cache editor like ccmake) while documenting which choices are sane.
Raef
________________________________________ From: Gyorgy Szing Gyorgy.Szing@arm.com Sent: 12 June 2020 06:56 To: David Hu; Adrian Shaw; Raef Coles; tf-m@lists.trustedfirmware.org Cc: nd; nd Subject: RE: CMake flags
Hi,
This requirement could be addressed with a user specific metadata file which is processed by the build-system. Implementation wise the easiest would be to include a file like UserCfg.cmake. This file could contain set(<option> CACHE <STRING|BOOL|PATH> “”) commands to set the option variables. User experience wise a text file parsed by cmake scripts would be the best. Such a file could contain variable=value lines. Longer term when Kconfig support is ready, it could cover these options too. Running Kconfig is a an act done less often, and most of the times, the user is expected to save the Kconfig input and output files. Most of the time the build-system would just use the pre-generated config. I imagine a workflow similar to the one used by the Linux Kernel.
Just my two cent’s though.
/George
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of David Hu via TF-M Sent: 12 June 2020 07:33 To: Adrian Shaw Adrian.Shaw@arm.com; Raef Coles Raef.Coles@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] CMake flags
Hi Adrian,
Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
Kconfig can bring some advantages:
* It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files. * Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
Best regards, Hu Ziji
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Friday, June 12, 2020 12:24 AM To: Raef Coles <Raef.Coles@arm.commailto:Raef.Coles@arm.com> Cc: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] CMake flags
Hi Raef. Thanks for the presentation today.
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
Adrian
tf-m@lists.trustedfirmware.org
-
David Hu -
Gyorgy Szing -
Raef Coles