CMake(enhance): Complete defconfig include support with menuconfig writeback capability

[xuxin930]

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 Cmake: add defconfig preprocess capability in Cmake build environment(recursively expand #include) #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

---

[xuxin930]

@wangchdo Could you please review the improvements in this PR: #16897

[xiaoxiang781216]

@xuxin930 please fix:

ab142962c1 cmake (enhance): Supports include-style defconfigs that can be modified via menuconfig
../nuttx/tools/checkpatch.sh -c -u -m -g a938926b5209e99a2008fece5a2e39fc07c62067..HEAD
❌ Commit subject too long > 80

[xuxin930]

@xuxin930 please fix:

ab142962c1 cmake (enhance): Supports include-style defconfigs that can be modified via menuconfig
../nuttx/tools/checkpatch.sh -c -u -m -g a938926b5209e99a2008fece5a2e39fc07c62067..HEAD
❌ Commit subject too long > 80

Done