fix(cmake): preserve Windows build OS metadata

[VectorPeak]

Description

Preserve the platform-derived build CPU/OS metadata when options.cmake registers BUILD_VER_CPUTYPE and BUILD_VER_OSTYPE as cache overrides.

What Problem This Solves

The top-level CMake load order is:

platform.cmake -> options.cmake -> version.cmake

platform.cmake computes platform metadata such as BUILD_VER_CPUTYPE=x64 and BUILD_VER_OSTYPE=Windows. options.cmake then declared the same names as empty cache strings, and version.cmake could fall back to generic defaults when those values were empty.

That could make a Windows configure report contradictory metadata:

Current system: Windows
cpu: x64
os: Linux

The cache entries still need to support user overrides such as -DBUILD_VER_OSTYPE=CustomOS and -DBUILD_VER_CPUTYPE=arm64, so the fix cannot simply hardcode platform values later in version.cmake.

Changes

options.cmake now handles both build metadata cache variables in two cases:

-set(BUILD_VER_CPUTYPE "" CACHE STRING "CPU type override")
-set(BUILD_VER_OSTYPE  "" CACHE STRING "OS type override")
+if(DEFINED CACHE{BUILD_VER_CPUTYPE} AND NOT "$CACHE{BUILD_VER_CPUTYPE}" STREQUAL "")
+  set(BUILD_VER_CPUTYPE "$CACHE{BUILD_VER_CPUTYPE}")
+else()
+  set(BUILD_VER_CPUTYPE "${BUILD_VER_CPUTYPE}" CACHE STRING "CPU type override" FORCE)
+endif()
+if(DEFINED CACHE{BUILD_VER_OSTYPE} AND NOT "$CACHE{BUILD_VER_OSTYPE}" STREQUAL "")
+  set(BUILD_VER_OSTYPE "$CACHE{BUILD_VER_OSTYPE}")
+else()
+  set(BUILD_VER_OSTYPE "${BUILD_VER_OSTYPE}" CACHE STRING "OS type override" FORCE)
+endif()

• If a non-empty cache value already exists, it is treated as the user's explicit override and copied back into the normal variable.
• Otherwise, the platform values computed by platform.cmake are used as the cache defaults.

Evidence

A minimal CMake script that simulates the relevant variable/cache sequence now preserves platform defaults and explicit overrides:

Windows x64 default:
-- cpu: x64
-- os: Windows
Linux arm64 default:
-- cpu: arm64
-- os: Linux
Overrides:
-- cpu: arm64
-- os: CustomOS

A real Windows configure reached the version block with corrected defaults:

cmake -S . -B %TEMP%\tdengine-cmake-buildver-default -G "Visual Studio 17 2022" -A x64 -DBUILD_CONTRIB=OFF -DBUILD_ROCKSDB=OFF -DBUILD_TOOLS=OFF -DBUILD_TEST=OFF -DBUILD_USE_PUBLIC_DEPS=ON
-- Current system: Windows
-- cpu:        x64
-- os:         Windows

The same configure with explicit overrides preserved the user values:

cmake -S . -B %TEMP%\tdengine-cmake-buildver-override -G "Visual Studio 17 2022" -A x64 -DBUILD_CONTRIB=OFF -DBUILD_ROCKSDB=OFF -DBUILD_TOOLS=OFF -DBUILD_TEST=OFF -DBUILD_USE_PUBLIC_DEPS=ON -DBUILD_VER_OSTYPE=CustomOS -DBUILD_VER_CPUTYPE=arm64
-- Current system: Windows
-- cpu:        arm64
-- os:         CustomOS

Both configure attempts later stopped in the external dependency stage because the local checkout does not have the cached prebuilt RocksDB artifact; the corrected cpu: and os: metadata is printed before that unrelated stop.

Possible call chain / impact

CMakeLists.txt
  -> include(cmake/platform.cmake)  # sets BUILD_VER_CPUTYPE / BUILD_VER_OSTYPE from platform
  -> include(cmake/options.cmake)   # registers cache overrides without erasing defaults
  -> include(cmake/version.cmake)   # prints and stores build metadata

This change is limited to build metadata initialization. It does not alter platform detection, compiler flags, dependency selection, or user-provided non-empty BUILD_VER_CPUTYPE / BUILD_VER_OSTYPE overrides.

Checklist

Please check the items in the checklist if applicable.

• Is the user manual updated?
• Are the test cases passed and automated?
• Is there no significant decrease in test coverage?

[gemini-code-assist]

Code Review

This pull request updates cmake/options.cmake to robustly handle the BUILD_VER_OSTYPE cache variable, preventing it from being cleared or shadowed during configuration runs. Feedback suggests applying the same pattern to BUILD_VER_CPUTYPE, which suffers from the exact same shadowing and first-run clearing issue.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The variable BUILD_VER_CPUTYPE suffers from the exact same shadowing and first-run clearing issue as BUILD_VER_OSTYPE. In cmake/platform.cmake, BUILD_VER_CPUTYPE is initialized as a normal variable (e.g., SET(BUILD_VER_CPUTYPE "x64")). Then, in cmake/options.cmake (line 15), it is declared as a cache variable: set(BUILD_VER_CPUTYPE "" CACHE STRING "CPU type override"). On the first configure run, this clears the normal variable, resulting in an empty BUILD_VER_CPUTYPE in version.cmake. On subsequent runs, the normal variable set by platform.cmake shadows any user-provided cache override (e.g., -DBUILD_VER_CPUTYPE=arm64). To resolve this, please apply the same robust pattern to BUILD_VER_CPUTYPE as well: if(DEFINED CACHE{BUILD_VER_CPUTYPE} AND NOT "$CACHE{BUILD_VER_CPUTYPE}" STREQUAL "") set(BUILD_VER_CPUTYPE "$CACHE{BUILD_VER_CPUTYPE}") else() set(BUILD_VER_CPUTYPE "${BUILD_VER_CPUTYPE}" CACHE STRING "CPU type override" FORCE) endif()

[VectorPeak]

Addressed the reviewer suggestion by applying the same cache/normal-variable preservation pattern to BUILD_VER_CPUTYPE as well as BUILD_VER_OSTYPE.

Validation run locally:

Windows x64 default:
-- cpu: x64
-- os: Windows
Linux arm64 default:
-- cpu: arm64
-- os: Linux
Overrides:
-- cpu: arm64
-- os: CustomOS

A real Windows configure also reached the version block with cpu: x64 / os: Windows, and with explicit overrides preserved cpu: arm64 / os: CustomOS. Both configure attempts later stopped at the unrelated cached RocksDB artifact check, after the build metadata had already been printed.