xuxin930 opened a new pull request, #17857:
URL: https://github.com/apache/nuttx/pull/17857
## Summary
This pull request completes the defconfig `#include` support for the CMake
build system, enabling full round-trip editing via `menuconfig`. This work
builds upon the foundation laid in PR #16897, which added CMake support for
preprocessing `#include` directives in defconfig files.
### Background
In PR #16897, we introduced CMake support for:
- Parsing and expanding `#include` directives in defconfig files
- Converting multi-file modular configurations into a single processed
`.config` file for Kconfig
- Building configuration from nested, include-based defconfig hierarchies
However, this implementation had a critical limitation: **users could only
read from include-based defconfigs, not write back to them**. When running
`make menuconfig`:
1. The system would read and expand the include-based defconfig correctly
2. After user modifications, the expanded `.config` would be saved
3. **But the modular include structure was lost** — the output would be a
flat defconfig without any `#include` directives
### Solution
This enhancement introduces a **bidirectional defconfig processing
pipeline** that preserves the modular structure through menuconfig operations:
#### Phase 1: Preprocessing with Tree Structure Capture
- Enhanced `process_config.py` to build a detailed hierarchical tree during
`#include` expansion
- Tree captures:
- The original `#include` directives and their locations
- Which configurations come from each included file
- The complete inclusion hierarchy in JSON format (`config_tree.json`)
- Original raw content of files for postprocessing
#### Phase 2: Original Configuration Snapshot
- Modified `nuttx_kconfig.cmake` to save the original expanded defconfig as
`defconfig.orig`
- This serves as a baseline for comparing user changes after menuconfig
modification
#### Phase 3: Change Detection & Reconstruction
- New `postprocess()` function in `process_config.py` that:
- Compares original vs. modified configurations to identify actual user
changes (added/changed/removed)
- Uses the tree structure to understand which changes were in included
files vs. main file
- **Intelligently reconstructs the defconfig** while preserving the
original `#include` structure
- Applies user changes to the correct location:
- Changes to included-file configs go back to the main defconfig
(overriding includes)
- Main file configs are preserved as-is
- Newly added configs go to the main defconfig
- **Prevents configuration sparsity** by preserving original non-default
values from the main file
#### Phase 4: Integration with menuconfig
- Updated `menuconfig.cmake` to call postprocessing after Kconfig
savedefconfig
- Saves the final intelligently-reconstructed defconfig that maintains
structure
---
## Impact
### Build System
- **Fully Backward Compatible**: Non-include-based defconfigs work exactly
as before
- **No Performance Regression**: Tree building only happens when `#include`
directives are present
- **New Generated Files** (temporary build artifacts):
- `config_tree.json`: Tree structure for postprocessing
- `defconfig.orig`: Original expanded config for change detection
- `config_tree_dirty.json`: For incremental builds with modifications
- These are created in `${CMAKE_BINARY_DIR}` and don't affect final output
### User Workflows
- **Modular Configurations Preserved**: Users can now use hierarchical,
include-based defconfigs and edit them with `menuconfig` without losing
structure
- **No Behavioral Change**: Existing single-file defconfigs continue to work
exactly as before
### Developer Experience
- **Debugging Support**: `config_tree.json` provides visibility into
configuration hierarchy
## Testing
1. **Basic Round-trip Testing**
- Create defconfig with `#include` directives
- Run `make menuconfig` and make some changes
- Verify `#include` directives are preserved in output
- Verify only changed configs appear in output
2. **Change Type Testing**
- Add new configuration
- Modify existing configuration
- Remove configuration
- Verify each type is handled correctly
3. **Include Level Testing**
- Single-level includes
- Multi-level includes (nested)
- Multiple includes in same file
- Circular include detection
### Migration Path
- **No user action required** for existing non-include-based defconfigs
- Teams wanting to adopt modular configurations can refactor their
defconfigs to use `#include` at their own pace
- The system gracefully handles mixed scenarios (some boards with includes,
some without)
---
## Benefits
1. **Completes the Include Feature**: PR #16897 read-only support → this PR
adds full read/write support
2. **Enables Best Practices**: Teams can use modular, maintainable
configuration structures
3. **Improves Developer Experience**: `menuconfig` now preserves
configuration organization
---
--
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]
