[pmeems]

Phase 1 of the CMake migration plan: CMake foundation and the MapWinGIS.Core DLL. The MSBuild .slnx build is unchanged and stays the supported build until the later phases land.

Changes

• Root CMakeLists.txt (CMake 3.28+, project(MapWinGIS6 VERSION 6.0.0 LANGUAGES C CXX)), restricted to Debug;Release.
• cmake/MwgVcpkg.cmake: runs before project(). Resolves the vcpkg root (MWG_VCPKG_ROOT, ../vcpkg, VCPKG_ROOT, as bootstrap-vcpkg.ps1 does), pins the triplets, and uses its own install tree vcpkg_installed/cmake-<Platform>. The tests feature follows MWG_BUILD_TESTS.
• cmake/MwgPlatform.cmake: checks MSVC ≥ 19.50 (v145), that the architecture matches the triplet (a fatal error with a CLion hint), and the Windows SDK (pinned for VS, a warning under Ninja).
• cmake/MwgFlagOverrides.cmake and cmake/MwgCompilerOptions.cmake: CMake's MSVC default flags (/DWIN32 /D_WINDOWS ...) are cleared, and mwg_apply_common_options() applies the audited MSBuild options PRIVATE per target. That includes _WINDLL, /JMC, PDBs in Release, and the Win32 defaults /Oy- /analyze- /SAFESEH.
• cmake/MwgRuntimeDeploy.cmake: MapWinGIS.RuntimeData copies share/gdal → gdal-data and share/proj → proj, using a stamp file. It keeps MWG_DEPLOY_RUNTIME_DATA and the missing-data warning.
• src/MapWinGIS.Core/CMakeLists.txt: explicit source lists with source_group(TREE), PUBLIC include/, PRIVATE src/, DEFINE_SYMBOL MWG_CORE_BUILD, and PRIVATE GDAL::GDAL GEOS::geos_c.
• CMakePresets.json: Ninja x64-debug|release and x86-debug|release, plus vs2026-x64|x86 (-T v145), with matching build and test presets. Output goes to out/b/<preset>/bin, never to bin/.
• Parity script: case-insensitive link options, an "explained" list for deliberate link differences, and a warning when a binary was not relinked.
• Docs: CMake section in BUILDING.md, parity status in CMAKE-MIGRATION.md.

Verification

• The parity script reports 0 lost compile/link options and 0 warnings for Core in Debug and Release, x64 and Win32.
• dumpbin: identical dependents, 260 exports, subsystem and DLL characteristics. The embedded manifest is byte-identical.
• The VS presets configure and build (x64 Debug/Release, x86 Debug).
• MSBuild Debug|x64 still builds; 173 tests run (170 pass, 3 skipped as before). The two output trees don't overlap.
• Configure rejects RelWithDebInfo and an architecture/triplet mismatch.

Explained differences

The manifest switches are handled by CMake's link wrapper. vcpkg auto-link is replaced by explicit imported targets. odbc32/odbccp32 are unused MSBuild defaults, and /TLBID:1 only matters for the OCX. The imported targets add /I.../include/geos and, in Debug, GDAL_DEBUG.

Known limitations

• CLion profiles were not verified interactively.
• Ninja cannot pin the Windows SDK.
• The Core tests run under CMake from Phase 3.

Dependencies

Stacked on #39 (Phase 0, cmake-phase-0-audit).

[Julian-MW]

Automated review. Final decision is with the human reviewer.

(Line-anchored posting was unavailable, so each finding carries its file:line.)

1. src/MapWinGIS.Core/CMakeLists.txt:31 — Severity: Major | Confidence: High

Issue: The CMake source lists are missing the files the MSBuild project compiles: src/map/Map.cpp, src/map/MapView.cpp, src/map/Viewport.cpp, src/rendering/MapRenderScene.cpp, plus the headers include/mapwingis/map/Map.h, MapView.h, Viewport.h, include/mapwingis/rendering/MapRenderScene.h and src/internal/VectorRenderSceneBuilder.h (all present in MapWinGIS.Core.vcxproj at this head).
Impact: The CMake-built MapWinGIS.Core.dll silently loses the Map, MapLayer and CreateMapRenderScene exports (MWG_CORE_API); the DLL still links, so nothing fails at build time. This also contradicts the PR's verification claim of identical exports (260) — either the lists drifted after the parity run, or the parity script does not compare source lists. CI only builds MSBuild, so this cannot be caught there.
Fix: Add the missing sources/headers to the CMake lists and extend the parity check (or a configure-time glob check) so the two source sets cannot drift.

2. docs/BUILDING.md:236 — Severity: Minor | Confidence: High

Issue: The new "### Building with CMake" content is inserted as a second ## CMake migration section, and the To measure flag and binary parity... paragraph (with its It finds MSBuild... continuation) now appears twice — once in the old section and again at the end of the new one.
Impact: Duplicate headings and a duplicated paragraph in the user-facing build documentation.
Fix: Merge into the existing ## CMake migration section and drop the re-added parity paragraph (or move it above the section and delete the original).

3. CMakeLists.txt:15 — Severity: Minor | Confidence: High

Issue: option(MWG_BUILD_SAMPLES ...) is declared and documented in the BUILDING.md options table, but nothing consumes it — no feature is added, no subdirectory is guarded by it.
Impact: Users setting -DMWG_BUILD_SAMPLES=OFF get no effect; the option table over-promises. It will also rot until samples land in a later phase.
Fix: Remove the option (and its docs row) until a later phase wires it up, or add a message(STATUS ...) noting it is reserved.

4. cmake/MwgCompilerOptions.cmake:66 — Severity: Minor | Confidence: Medium

Issue: MWG_ENABLE_ASAN adds /fsanitize=address but leaves CMake's default linker flags untouched. Only CMAKE_<LANG>_FLAGS*_INIT was overridden; CMAKE_<LANG>_FLAGS_DEBUG linker defaults still contain /INCREMENTAL (Debug), which MSVC's AddressSanitizer is incompatible with.
Impact: -DMWG_ENABLE_ASAN=ON in a Debug configuration likely fails to link or silently disables ASan instrumentation on Ninja/vcvars builds.
Fix: When ASAN is on, also add /INCREMENTAL:NO to target_link_options for all configs, and consider /Od documentation (MSVC ASan ignores optimization incompatibilities only partially).

5. cmake/MwgVcpkg.cmake:83 — Severity: Suggestion | Confidence: Low

Issue: VCPKG_HOST_TRIPLET defaults to the hard-coded x64-windows-v145.
Impact: On an ARM64 Windows host, vcpkg host tools would be built for x64 and run under emulation instead of natively.
Fix: When the host processor is ARM64, default the host triplet to an arm64-windows-v145 overlay triplet if one exists, keeping x64 otherwise.

6. cmake/MwgRuntimeDeploy.cmake:34 — Severity: Suggestion | Confidence: Medium

Issue: -E copy_directory_if_different only copies and overwrites; it never deletes files in gdal-data/proj that disappeared from the vcpkg share tree (e.g. after a GDAL downgrade or feature change in the same install tree).
Impact: Stale data files linger in the runtime folder and can shadow or conflict with the current GDAL/PROJ versions.
Fix: Remove the destination directories before copying (e.g. cmake -E rm -rf then copy_directory_if_different), accepting the slightly larger copy on data changes.

7. CMakeLists.txt:3 — Severity: Suggestion | Confidence: High

Issue: The CMake build has no CI coverage; the check runs only build MSBuild (Debug x64 passed, Release in progress at review time).
Impact: Regressions like finding 1 (source lists drifting from the .vcxproj, wrong flags, preset breakage) cannot be caught automatically and rely on manual parity runs per phase.
Fix: Add a workflow job that configures and builds one CMake preset (e.g. x64-debug) on the Windows runner; it is cheap once vcpkg's binary cache is warm and would have caught finding 1 immediately.

Duplicates skipped: 0 (no existing comments on this PR).

[pmeems]

Fixed in 08c943a: Restored the missing Core sources and headers, added configure-time MSBuild/CMake list checks and CMake CI coverage, corrected ASan and runtime-data handling, and removed the duplicate build-guide content. The ARM64 host-triplet suggestion was not changed because the repository has only x64 and x86 overlay triplets.