[Swatantra-66]

Summary

Addresses apache/nuttx#19549 by closing the CMake build-system parity gap in apps/audioutils

1. audioutils/morsey:
   Adds CMakeLists.txt using CMake FetchContent to download the upstream v1.0.1 release tarball.
   Implements automated SHA-256 integrity verification for morsey.c and morsey.h matching Makefile.
   Exports the public header via symlink to ${NUTTX_APPS_BINDIR}/include/audioutils/morsey.h.
   Compiles morsey.c and registers private include paths with the apps library target.

2. audioutils/rtttl-c:
   Adds CMakeLists.txt using CMake FetchContent to shallow clone tag v0.1.0.
   Implements automated SHA-256 integrity verification for rtttl.c and rtttl.h matching Makefile.
   Exports the public header via symlink to ${NUTTX_APPS_BINDIR}/include/audioutils/rtttl.h.
   Compiles rtttl.c and registers private include paths with the apps library target.

3. Robustness & Edge-Case Safety (both modules):
   Preapps Safety: Conditioned on if(CONFIG_* AND TARGET apps) to prevent premature evaluation during early Kconfig generation.
   Offline Build Overrides: Honors FETCHCONTENT_SOURCE_DIR_MORSEY_FETCH and FETCHCONTENT_SOURCE_DIR_RTTTL_C_FETCH without attempting network access.
   Local Edit Preservation: Rejects missing/incomplete checkouts with a fatal error if local files exist, refusing to delete developer modifications or Make checkouts.
   Subbuild Reset: Wipes sub-build state under ${FETCHCONTENT_BASE_DIR} to ensure recovery when a fresh download is needed.
   Symlink Refresh: Unconditionally invokes nuttx_create_symlink to refresh exported header links whenever the active source directory changes.

Impact

New feature added: Yes, CMake build support for audioutils/morsey and audioutils/rtttl-c.
Existing behavior changed: No, existing Make builds remain 100% untouched.
Build process: Enables building both modules when configuring with CMake (-DCONFIG_AUDIOUTILS_MORSEY=y and -DCONFIG_AUDIOUTILS_RTTTL_C=y).
Compatibility: Fully compliant with cmake-format (0 warnings/errors).

Testing

Host: Ubuntu 24.04 (WSL2 / Windows 11 x86_64), GCC 15.2.0, CMake 4.2.3, Ninja 1.13.2
Target: sim:nsh (-DCONFIG_AUDIOUTILS_MORSEY=y -DCONFIG_AUDIOUTILS_RTTTL_C=y)

Build Logs:

-- Populating morsey_fetch
[1/9] Performing download step (download, verify and extract) for 'morsey_fetch-populate'
-- extracting... done
[9/9] Completed 'morsey_fetch-populate'
-- Populating rtttl_c_fetch
[1/9] Performing download step (git clone) for 'rtttl_c_fetch-populate'
Cloning into 'rtttl-c'...
HEAD is now at a093e61 Release under Apache-2.0, too
[9/9] Completed 'rtttl_c_fetch-populate'
-- Build files have been written to: .../build_audiotest
ninja: Entering directory `build_audiotest'
[3/35] Building C object apps/CMakeFiles/apps.dir/audioutils/morsey/morsey/morsey.c.o
[8/35] Building C object apps/CMakeFiles/apps.dir/audioutils/rtttl-c/rtttl-c/rtttl.c.o
[35/35] Linking C static library apps/libapps.a

Style & Format Verification:

cmake-format --check apps/audioutils/morsey/CMakeLists.txt
cmake-format --check apps/audioutils/rtttl-c/CMakeLists.txt
100% CMAKE-FORMAT COMPLIANT

[Swatantra-66]

Removed the SHA checks and streamlined both CMakeLists.txt to follow the standard NuttX FetchContent pattern matching other submodules

[acassis]

@simbit18 what if we add a rule on CI to automatically detect with a Makefile is created/modified but there is no modification on CMakefile? This way we enforce them to keep in sync and we avoid starting the CI for some PR that is not right. It will require a commit to approval when this Make/CMake mismatch happen, like when a new user submit a PR for the first time.

There is only a drawback where someone could be fixing a real issue that exists only on a specific Makefile and it is already fine on CMake, but this is a rare case. And the human could approve and let the CI run.

[Swatantra-66]

@acassis Enforcing this in the fast check.yml / lint.yml workflow would prevent build-system divergence before the heavy matrix even spins up
To handle the edge case where a fix is truly Make-specific (or vice-versa), we could allow a PR label like ci:make-only or a keyword in the commit message to bypass the check, while requiring parity by default for new directories and general source additions

[acassis]

@acassis Enforcing this in the fast check.yml / lint.yml workflow would prevent build-system divergence before the heavy matrix even spins up To handle the edge case where a fix is truly Make-specific (or vice-versa), we could allow a PR label like ci:make-only or a keyword in the commit message to bypass the check, while requiring parity by default for new directories and general source additions

Nice, do you want to implement too?

[Swatantra-66]

Yes
Here is a quick outline

Fast-fail check in CI - Run early in .github/workflows/check.yml (before the heavy matrix builds spin up).
Detection Logic - Check git diff against the base ref (origin/master...HEAD). If a Makefile or Make.defs in a directory is created or modified, verify that CMakeLists.txt in that same directory (or parent component) is also created/modified.
Bypass mechanism - If a PR has a label (e.g., ci:make-only) or a commit message tag (e.g., [skip-cmake-check]), allow it to pass so legitimate Make-only bug fixes aren't blocked.

@acassis, would you prefer this integrated as a new option in tools/checkpatch.sh (so contributors can also test it locally with ./tools/checkpatch.sh -g HEAD~1..HEAD), or as a dedicated step in .github/workflows/check.yml?

[acassis]

Yes Here is a quick outline

Fast-fail check in CI - Run early in .github/workflows/check.yml (before the heavy matrix builds spin up). Detection Logic - Check git diff against the base ref (origin/master...HEAD). If a Makefile or Make.defs in a directory is created or modified, verify that CMakeLists.txt in that same directory (or parent component) is also created/modified. Bypass mechanism - If a PR has a label (e.g., ci:make-only) or a commit message tag (e.g., [skip-cmake-check]), allow it to pass so legitimate Make-only bug fixes aren't blocked.

@acassis, would you prefer this integrated as a new option in tools/checkpatch.sh (so contributors can also test it locally with ./tools/checkpatch.sh -g HEAD~1..HEAD), or as a dedicated step in .github/workflows/check.yml?

@Swatantra-66 I think only a check in checkpatch.sh should be enough

[Swatantra-66]

@acassis as discussed , I have opened PR apache/nuttx#21012