Thanks for the careful fix and the clear root-cause writeup, @gauthig — this correctly untangles the /MANIFEST:EMBED vs. CMake's vs_link_exe/mt.exe machinery.

The approach is sound. Listing the .manifest as a target source is the CMake-native way to embed it: CMake feeds it to its own mt.exe step, so the two no longer fight over who owns embedding. I confirmed there's no double-embed hazard — packaging/windows/AetherSDR.rc only declares IDI_ICON1 ICON, not an RT_MANIFEST resource, so nothing else is trying to embed a manifest. The change is correctly scoped inside the if(MSVC) block and uses CMAKE_SOURCE_DIR consistently with the WIN_RC handling just above it. Both files are in scope for the issue.

One minor, non-blocking note on the README: the new Windows 11 section lists Ninja as a prerequisite but the configure command (cmake -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo) doesn't pass -G Ninja. With VS Build Tools installed, CMake's default generator is the Visual Studio generator, not Ninja — so a reader following the steps verbatim won't actually exercise the Ninja path this fix was reproduced against. The fix works under both generators, so this is purely a docs-consistency nit; consider adding -G Ninja (or dropping Ninja from the prereq list) to match intent.

Nice work — the reporter-confirmed link success plus the build.ninja inspection is exactly the kind of evidence that makes a build fix easy to trust.

_{🤖 aethersdr-agent · cost: $1.5081 · model: claude-opus-4-8}

Approving — the fix is correct and it's the right long-term idiom. Verified against CMake's own source (Source/cmcmd.cxx, cmVSLink) plus the repo history; two findings worth putting on the record:

One correction to the root-cause attribution: it's the incremental link path, not cmake 4.x

vs_link_exe parses only /INCREMENTAL[:YES|NO] and /MANIFEST:NO from the link command — it does not recognize /MANIFEST:EMBED. What actually forks the behavior is the link mode:

• Incremental (Debug / RelWithDebInfo, whose default MSVC linker flags are /debug /INCREMENTAL): vs_link_exe runs its rc/link/mt embed dance and expects link.exe to emit a side-car manifest. The hand-passed /MANIFEST:EMBED makes link.exe embed inline and emit no side-car, so mt.exe gets zero /manifest inputs plus /notify_update → c10100a7. This behaves identically on cmake 3.x — the code path is years old.
• Non-incremental (Release, /INCREMENTAL:NO): vs_link_exe delegates embedding to link.exe entirely and runs no mt step, so the hand-passed flags happen to work.

That's why CI never caught it despite already running CMake 4.3.4 on the windows-2025-vs2026 image: check-windows builds Release. You were simply the first person to do an incremental MSVC build since #3237 merged. (Bonus: pre-#3237, incremental builds on lenient toolsets likely shipped with no DPI manifest at all, since the lone /MANIFESTINPUT was ignored — this PR closes that hole too.)

The squash commit message will carry the corrected attribution so future archaeology on these six lines doesn't chase cmake versions.

This PR became release-blocking this morning

#3934 (merged Jul 1) switched windows-installer.yml — the Microsoft Store / release pipeline — from Release to RelWithDebInfo for PDB/.appxsym symbol packaging. That moves the release link onto the incremental path, so without this fix the next v* tag fails at link with exactly this c10100a7. No run of that workflow has executed since the switch; this PR needs to land first.

Verification story

• Reporter-confirmed on the incremental path (RelWithDebInfo, cmake 4.3.2, MSVC 14.44) ✔
• check-windows green on the non-incremental path (Release, cmake 4.3.4, MSVC 19.51) ✔ — and on that path vs_link_exe itself appends /MANIFEST:EMBED,ID=1 + /MANIFESTINPUT:<manifest>, i.e. exactly what #3237 hand-coded, now generated coherently. Release artifacts should carry a byte-equivalent embedded manifest.
• No double-embed hazard: AetherSDR.rc declares only the icon, no RT_MANIFEST.
• Post-merge I'll dispatch windows-installer.yml on main to validate the full RelWithDebInfo Store path — the check-dpi-awareness.ps1 step hard-gates the embed, and it exercises #3934's -RequirePdb plumbing in the same run.

Follow-up (not this PR): consider aligning check-windows to RelWithDebInfo so PR CI exercises the same link path the release pipeline ships.

Thanks @gauthig for the careful repro and bisect — exemplary first contribution.