RFC: Encapsulating Windows/MSVC portability support in Velox

[tinadu1018]

Hi Velox maintainers,

I opened PR #17897 to contribute Windows/MSVC support for Velox. Based on feedback from @Yuhta, I’d like to discuss the design first, specifically how to encapsulate platform-dependent changes so Windows support does not add long-term maintenance noise across the codebase.

Related prior issue: #6274.

Goal

Enable contributor-maintained, best-effort Windows/MSVC support while keeping the impact on existing Linux/macOS development as small as possible.

The core concern is valid: the current PR is large and has too many _WIN32 / _MSC_VER guards spread across normal Velox files. I’d like to restructure the work, so platform-specific logic is mostly isolated behind a small number of portability/build layers.

Proposed approach

1. Isolate Windows build setup under dedicated files such as windows/vcpkg/..., Windows CMake presets/helper modules, and an optional non-required Windows CI workflow.

2. Centralize compiler and OS compatibility helpers in a small portability layer, for example velox/common/base/Portability.h, velox/common/base/windows/..., and velox/common/memory/windows/....

3. Prefer platform-specific implementation files selected by CMake over large inline #ifdef blocks in core logic, e.g. LocalFileWindows.cpp or ProcessBaseWindows.cpp.

4. Split PR Add Windows/MSVC support #17897 into smaller staged PRs: build skeleton, base portability helpers, memory/file/process abstractions, numeric/MSVC fixes, module-by-module fixes, and optional best-effort Windows CI.

Questions

1. Is this general direction acceptable?
2. Where would you prefer the portability layer to live?
3. Should we prefer centralized helpers, platform-specific implementation files, or a mix of both?
4. What order would be best for splitting PR Add Windows/MSVC support #17897?
5. Are there areas where Windows support should explicitly remain out-of-scope for now?

I’m not asking the core team to own Windows support. My goal is to contribute and maintain it in a way that keeps the burden low for existing Velox maintainers and contributors.