linguini1 commented on PR #18500:
URL: https://github.com/apache/nuttx/pull/18500#issuecomment-4013015634
> @linguini1 I think this is a great idea!
>
> I think the next step is to map all drivers and fs and build only board
configs that are using it, i.e.:
>
> If a PR modified the file "fs/fat/fs_fat32.c" then the script could
inspect the "fs/fat/CMakeLists.txt" and figure out that this file is compiled
when CONFIG_FS_FAT is enabled, then it could track which board configs are
using it.
>
> I'm not sure if it is easy to do, but comparing Make.defs vs
CMakeLists.txt, seems like CMakeLists.txt are easy to track. I think if you
search for second previous "(" symbol after finding the file position
(fs_fat32.c) it will find the right symbol. Just an idea!
This is a good idea, and the logical next step for sure. This will be
significantly more complex though, as instead of choosing builds based on the
changed file's path (as is currently possible for `board/` and `arch/` paths),
it requires some level of parsing `defconfig` files or at least determining
less obvious source file relationships.
One (very fresh and likely very naive) idea I had was to construct a
dependency graph for source files. I.e., each source file in the tree is
associated with a list of `defconfig` files that depend on it. Then, we can
take the changeset for a PR and look up the source files in this graph to see
what `defconfig` files need to be built.
Of course, this requires that we have the dependency graph in the first
place. I don't know how cheaply it can be generated by our build system (i.e.,
my thought is that CMake will know which build files are getting used for a
`defconfig` and we can take that output to stitch together the dependency
graph). It would have to be maintained/updated any time we add a `defconfig`
file, modify Kconfig files or update Make/CMake files. So it would have to be
automated and highly reliable. This is a big task and is far out in the future.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
