Jens-G opened a new pull request, #3901:
URL: https://github.com/apache/thrift/pull/3901

   [`dd8ecde06`](https://github.com/apache/thrift/commit/dd8ecde06) moved the 
project away from a statically linked Windows compiler. 
`doc/ReleaseManagement.md` has said so since:
   
   > The compiler is portable and folks find it useful to be able to download 
one … **It requires Visual C++ Runtime due to ASF regulations.**
   
   Two things were left behind by that change.
   
   ## The document still asked for the old property
   
   A few lines below that sentence it still said:
   
   > Verify the executable only depends on kernel32.dll using depends.exe.
   
   A compiler that links the shared runtime cannot satisfy that, so the 
instruction contradicted the paragraph above it and could not be followed.
   
   It now describes what is actually expected — Windows system DLLs and the 
Visual C++ runtime, and nothing else: no Boost, OpenSSL, zlib or libevent — 
plus an explicit note *not* to reach for a static build to shorten the list.
   
   ## The build still asked for the static runtime
   
   `-DWITH_MT=ON` was still passed by `build/docker/msvc/build-compiler.bat` 
and by the manual recipe in the same document. `WITH_MT` is the option whose 
whole purpose is to select the static runtime.
   
   It happens to do nothing. It is implemented by rewriting `/MD` → `/MT` in 
the per-configuration compiler flag variables, and 
[CMP0091](https://cmake.org/cmake/help/latest/policy/CMP0091.html) took the 
runtime library out of those variables and moved it to the 
`MSVC_RUNTIME_LIBRARY` target property. That policy is NEW whenever a project 
requires CMake 3.15 or newer, and the top-level `CMakeLists.txt` requires 3.16 
— so there is no `/MD` left to replace.
   
   So the released compiler links the shared runtime, which is what is wanted, 
**but by accident**. `WITH_MT` looks like a plain bug — I nearly "fixed" it — 
and repairing it would silently turn the release build back into the statically 
linked one the project deliberately moved away from.
   
   Both recipes now drop the flag, and `build-compiler.bat` says why it is not 
there.
   
   ## Why this is safe
   
   `WITH_MT` also sets `THRIFT_RUNTIME_POSTFIX`, which renames library 
artifacts (`thriftmt` / `thriftmd`). Neither recipe builds a library — 
`build-compiler.bat` passes `-DBUILD_LIBRARIES=OFF`, the VM recipe passes 
`-DWITH_CPP=OFF` — so nothing is renamed by this change.
   
   The option itself is untouched; only the two release recipes stop asking for 
it.
   
   ## Context
   
   This is the root of a small stack adding Windows compiler CI and packaging — 
[#3893](https://github.com/apache/thrift/pull/3893), then the installer, .NET 
tool, WinGet and Chocolatey packages. It goes first because the CI job added 
there asserts the compiler's import table, and this PR is what settles what 
that table is supposed to contain.
   
   JIRA: [THRIFT-6320](https://issues.apache.org/jira/browse/THRIFT-6320)
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to