This is an automated email from the ASF dual-hosted git repository. jimjag pushed a commit to branch msys2-dev-prototype in repository https://gitbox.apache.org/repos/asf/openoffice.git
commit fefcf25cecc0e53f43d6d9c440c2ef8d5faa59cc Author: Jim Jagielski <[email protected]> AuthorDate: Tue Aug 11 13:19:35 2026 -0400 Record the --with-system-* audit and correct where ATL comes from All 37 options are clear of Windows gating, so the externals phase can lean on MSYS2 packages as planned. ATL, though, looks like a Visual Studio Build Tools component rather than part of the standalone SDK, which weakens the "no Visual Studio at all" claim until the probe settles it. --- MSYS2-WINDOWS-BUILD-FEASIBILITY.md | 60 ++++++++++++++++++++++++++------------ 1 file changed, 41 insertions(+), 19 deletions(-) diff --git a/MSYS2-WINDOWS-BUILD-FEASIBILITY.md b/MSYS2-WINDOWS-BUILD-FEASIBILITY.md index 34c1c02532..3d55943278 100644 --- a/MSYS2-WINDOWS-BUILD-FEASIBILITY.md +++ b/MSYS2-WINDOWS-BUILD-FEASIBILITY.md @@ -38,9 +38,9 @@ from a standalone Windows SDK install. The maintenance argument is the strongest one for doing this at all. The current MSVC path is pinned to `COMEX` ≤ 12 — VS2008 (`set_soenv.in:715-723`, `configure.ac:2245`). -An MSYS2 build tracks a rolling, self-updating toolchain and depends on the Windows SDK -only as a small, explicitly-declared set of components that installs standalone without -Visual Studio. +An MSYS2 build tracks a rolling, self-updating toolchain and depends on Microsoft only +through a small, explicitly-declared set of components — a current Windows SDK and, for +ATL, a Build Tools component — rather than on one pinned IDE. ## Where each dependency comes from @@ -51,7 +51,7 @@ Visual Studio. | C runtime | **UCRT** | In-box on Windows 10+; see the MSVCRT question below | | Shell, perl, make, autotools, pkg-config | **MSYS2** | Replaces the Cygwin dependency | | Most bundled third-party libraries | **MSYS2 packages** via `--with-system-*` | 38 such options already exist in `configure.ac` | -| **ATL** | **Windows SDK** | mingw-w64 has none and no free ATL exists | +| **ATL** | **VS Build Tools** — *not* the standalone SDK, see below | mingw-w64 has none and no free ATL exists | | **MSI database tools** (`msidb`, `msitran`, `msiinfo`, `uuidgen`) | **Windows SDK** | `msitools`/WiX are not worth the effort | | **`signtool`** | **Windows SDK** | Only if producing signed builds | | ADO headers (`adoint.h`, `adodef.h`, …) | **Windows SDK** | Keeps the ADO database driver alive | @@ -60,10 +60,23 @@ Visual Studio. | DirectShow / Direct3D headers | **mingw-w64** | Legacy DirectX SDK not needed | | JDK | **native Windows JDK** | MSYS2 ships none | -Net effect: **no Microsoft compiler or build tooling at all**, and the Windows SDK -reduced to four discrete, auditable items. That is the dependency reduction that -actually matters — the SDK is a stable, versioned, standalone download, whereas the -current dependency is on a specific ancient Visual Studio. +Net effect: **the Microsoft compiler is not used at all**, and the Microsoft dependency +reduces to four discrete, auditable items. That is the reduction that actually matters — +a current, versioned SDK and (for ATL) a Build Tools component, versus today's dependency +on one specific ancient Visual Studio. + +**Correction, pending the probe.** An earlier draft claimed all four items come from a +standalone Windows SDK with no Visual Studio involvement. That is probably wrong for ATL: +modern ATL ships as a Visual Studio / VS Build Tools component under +`VC/Tools/MSVC/<ver>/atlmfc`, not under `Windows Kits`. AOO's own history points the same +way — `external/mingwheaders/makefile.mk:47` reads ATL out of `$(PSDK_HOME)/include/atl`, +i.e. the old Platform SDK, which today's standalone SDK is not a continuation of for this +purpose. + +If that holds, the honest statement is *"no Visual Studio IDE and no MSVC compiler, but +one Build Tools component for ATL"* — still a large reduction, but not the clean claim. +`msys2-probe.sh` searches both locations and settles it. The MSI tools and `signtool` are +genuinely Windows SDK, and are unaffected. ## The UCRT vs MSVCRT question @@ -124,7 +137,7 @@ are holding in reserve. If it is ever forced, the three items above are the bill | `__MINGW32__` conditionals | 100 files across the tree | | `solenv/bin/addsym-mingw.sh`, `_tg_def.mk` MinGW branches | Export/`.def` handling present | | ~20 external modules | Already have `WNT` + `COM=GCC` build recipes | -| `--with-system-*` | 38 options; the 8 spot-checked are not gated off on Windows | +| `--with-system-*` | 37 options; **audited — none is gated off on Windows** | All of it is 32-bit and none has had functional work in years — every recent commit touching these files is whitespace or mechanical. But the build system already @@ -202,11 +215,19 @@ from that path. Document as a limitation of the MSYS2 configuration. ### B4 — Externals via MSYS2 packages The biggest simplification available, and the one that most directly serves "easier and -more straightforward". `configure.ac` already exposes `--with-system-*` for nss, +more straightforward". `configure.ac` exposes 37 `--with-system-*` options — nss, openssl, icu, python, expat, libxml, libxslt, curl, boost, hunspell, hyphen, mythes, -graphite, redland, zlib, jpeg, mdds, vigra, libtextcat, cairo, coinmp and more — none -gated off on Windows, all pkg-config driven, and MSYS2 provides pkg-config and packages -for essentially all of them. +graphite, redland, zlib, jpeg, mdds, vigra, libtextcat, cairo, coinmp, poppler and more. + +**Audited in full: not one is gated off on Windows.** The only `_os` interactions are +Darwin force-on defaults (`zlib` at `configure.ac:3851`, `python` at `4126`, `curl` at +`4692`), a feature gate that explicitly *includes* WINNT (`graphite`, `5110`), and +feature gates unrelated to platform (`cairo` behind `test_cairo`, `poppler` behind +`enable_pdfimport`, `dicts` behind its own flag). All are pkg-config driven, and MSYS2 +supplies pkg-config. + +Which of them MSYS2 actually packages for the clang64 prefix is a separate question, and +the one thing here still unmeasured — `msys2-probe.sh` section 8 enumerates it. This deletes most of what was going to be a 4–8 week phase, and in particular sidesteps the worst single risk in the original assessment: **building the bundled Python 3 under @@ -367,10 +388,9 @@ three `__declspec(uuid)` sites in `avmedia`; the ATL reference counts per module the fact that `shlxthandler`/`setup` use `MFC_INCLUDE` for resources only; the absence of a 64-bit GCC dispatch in `wnt.mk`; the `__MINGW32__`/`sal_Unicode` handling; the PSDK dependency in `external/mingwheaders`; the installer's required-tools list in -`control.pm:105`; the existence of 38 `--with-system-*` options and the absence of Windows -gating in the 8 spot-checked (openssl, expat, libxml, curl, boost, hunspell, icu, nss — -the other 30 were not checked); the `COM=GCC` version-decoding path at -`configure.ac:2301` and the CCNUMVER gates named in B5a; the +`control.pm:105`; all 37 `--with-system-*` options and the absence of Windows gating in +every one of them (B4); the `COM=GCC` version-decoding path at `configure.ac:2301` and the +CCNUMVER gates named in B5a; the `COMEX` ≤ 12 ceiling on the MSVC path; and the staleness of the MinGW files in git history. @@ -384,8 +404,10 @@ Windows SDK install: - That clang's `-fms-extensions`/`-fms-compatibility` are sufficient to parse current Windows SDK ATL headers — **the highest-value thing to test first**, since it decides Phase 3's size. -- That the Windows SDK installs standalone without Visual Studio and that ATL is - available in that installation. +- **Where ATL actually comes from.** An earlier draft asserted the standalone Windows SDK + carries it; on reflection that is probably wrong (modern ATL is a VS Build Tools + component). Neither the old claim nor the correction has been verified on a real + machine — `msys2-probe.sh` section 6 searches both locations. - That mingw-w64 provides `comdef.h`, d3d9 and dshow headers, and that `widl` is an adequate `midl` replacement. - That MSYS2 packages exist and are usable for the `--with-system-*` set named above.
