Skip to content

how to retrieve a active build option (including board, app name and additional configs)for given CONFIG item #42663

Unanswered
hakehuang asked this question in General
how to retrieve a active build option (including board, app name and additional configs)for given CONFIG item #42663
Feb 10, 2022 · 1 answers · 4 replies

in zephyr, many features are configured by Kconfig options, and if we have a code change in a given .c file and I can get the build config from the cmakefile which uses this .c file, but how to find a correct build option including board, and active application for this config?

for example, if I change the dma_mcux_edma.c, and I know the config is CONFIG_DMA_MCUX_EDMA, I can also find the related test application from MIANTAINER.yml, which is ('tests\drivers\dma\chan_blen_transfer', 'tests\drivers\dma\chan_link_transfer', 'tests\drivers\dma\loop_transfer') but which platform shall be built for this application? how can I retrieve those information without build all the applications?

Replies

1 suggested answer
·
4 replies

I understood from our discussion, that you would like to have a map, matching applications (tests and samples) with KConfig options which are used when the application is build with respect to the given platforms. Then, such map could be used when defining testing scope for PRs in the CI, by providing a list of other configurations (test/sample + platform) involving the same Kconfig option which is affected in a PR. Did I get it correct @hakehuang ?
@tejlmand @gmarull Do you think it is feasible?

4 replies
@tejlmand

First question to @hakehuang , did you look at the --cmake-only option ?
That should allow you to just run the CMake part, not a full build, which is significantly faster than to build everything.
After a CMake run you'll have all generated .configs available and you can do any filtering you would like.

For the rest of the proposal, then this sound like something that will be almost impossible to keep track of.

Remember that a sample / test

  • may use prj.conf to set a given value.
  • may create a Kconfig file for the sample / test which sets a value.
  • may specify extra configs using: extra_configs: in testcase.yaml (tests only)
  • may be expected to build with a Kconfig fragment injected using -DCONFIG_OVERLAY=<file>
  • could be selected by a different Kconfig symbol
  • coming from a shield
  • .... and endless other possibilities.

the only practical solution to this would be to update twister to support the use of package_helper: #41302

We have already discussed adopting twister to use package helper to be able to just run Kconfig / dts, and through that filter tests / samples / boards that must be executed for a full build.

Using same approach, it might be possible to have an early twister test / sample abort feature where you could request twister to not do a full build, but only the Kconfig part, similar to --cmake-only.
That way one could do just the Kconfig part for all samples / tests / board combination.
This should further reduce time it takes, compared to a --cmake-only build.

@hakehuang

hakehuang Mar 8, 2022
Collaborator Author

@tejlmand , thanks a lot for replying. To identify which test can cover what marco, we still need build all possible tests with '--cmake-only'. So would there be a way that we can generate a static map for all tests into a file, and increamentally update it. When checking marco, we can read that generated map file and get a list of related platform and tests apps, and its configurations?

@tejlmand

I know twister can generate reports with test result, also in json format, but that will only give you overview of what tests has been executed and their result (see twister --help). I believe build folder reference is also part of the report, but @PerMac can probably provide more details on this matter.

Using build info knowledge together with the <build_folder>/zephyr/.config file should give you what you need, but you would need to create your own map based on the information provided by those files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Build System area: Tests
3 participants