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
The following commit(s) were added to refs/heads/msys2-dev-prototype by this
push:
new 8cd8752060 Baseline the clang-cl alternative to the GNU-ABI Windows
build
8cd8752060 is described below
commit 8cd8752060979fdf1e66278002000ad755db2b5e
Author: Jim Jagielski <[email protected]>
AuthorDate: Tue Aug 11 14:12:11 2026 -0400
Baseline the clang-cl alternative to the GNU-ABI Windows build
Keeping the MSVC ABI deletes both of the other plan's dominant items: ATL
needs no
port, and the Win64 UNO bridge already exists and is being fixed in flight,
so the
go/no-go gate goes with it -- 1.5-3 person-months against 5-9.
What it costs is less obvious and is recorded here: MSYS2's packages are
GNU-ABI, so
none of the 24 system libraries can be linked into an MSVC-ABI build, and
MSYS2's role
narrows to the host shell.
---
CLANG-CL-WINDOWS-BUILD-BASELINE.md | 234 +++++++++++++++++++++++++++++++++++++
1 file changed, 234 insertions(+)
diff --git a/CLANG-CL-WINDOWS-BUILD-BASELINE.md
b/CLANG-CL-WINDOWS-BUILD-BASELINE.md
new file mode 100644
index 0000000000..274d8b0320
--- /dev/null
+++ b/CLANG-CL-WINDOWS-BUILD-BASELINE.md
@@ -0,0 +1,234 @@
+# Baseline: clang-cl + MSYS2 Windows build
+
+Companion to `MSYS2-WINDOWS-BUILD-FEASIBILITY.md`. That document assesses a
+GNU-ABI build (MSYS2 CLANG64, `x86_64-w64-windows-gnu`, libc++) at **5–9
+person-months**. This one assesses the alternative the ATL measurement pushed
us
+toward: **keep the MSVC ABI, swap `cl.exe` for `clang-cl`, and move the shell
from
+Cygwin to MSYS2.**
+
+**Estimate: roughly 1.5–3 person-months**, and materially less risk, because
the
+single hard blocker of the other plan — a from-scratch Win64 UNO bridge — does
not
+exist here. The trade is a permanent VS Build Tools dependency and the loss of
the
+`--with-system-*` simplification.
+
+## Why this is so much cheaper
+
+The MSYS2 plan's two dominant line items both disappear:
+
+| MSYS2/GNU-ABI plan | clang-cl plan |
+|---|---|
+| Phase 1: write a Win64 GNU-ABI UNO bridge (6–10 wks, go/no-go gate) |
**Already exists** — `msvc_win64_x86-64`, wired, actively being fixed |
+| Phase 3: de-ATL port (6–10 wks, measured as required) | **Not needed** — ATL
is fine under the MSVC ABI |
+
+That is 12–20 weeks removed, and with it the only item that could have
invalidated
+the whole effort.
+
+## What already exists in the tree
+
+The 64-bit Windows MSVC path is scaffolded end to end. Verified by inspection:
+
+| Piece | State |
+|---|---|
+| `configure.ac:275` `--enable-win64` | Present; defaults to `no`, help text
says "doesn't fully build on Windows yet" |
+| `configure.ac:1334-1355` `BUILD_WIN64` | Set and `AC_SUBST`ed |
+| `set_soenv.in:726-737` | `CPU=X`, `CPUNAME=X86_64`, `OUTPATH=wntmscx@COMEX@`
|
+| `solenv/inc/wnt.mk:42` | Dispatches `WNTMSCX` → `wntmscx.mk` |
+| `solenv/inc/wntmscx.mk` | 405 lines, present |
+| `bridges/Library_cpp_uno.mk:601` | Full `WNT-X86_64-mscx` branch: 5
exception objects + MASM `call` |
+| `bridges/source/cpp_uno/msvc_win64_x86-64/` | 8 files: `abi`, `cpp2uno`,
`uno2cpp`, `except`, `dllinit`, `call.asm` |
+| `configure.ac:2210` | `cl_subdirectory="bin/amd64"` when `BUILD_WIN64` |
+
+**And it is under active development right now**, which is the most important
fact
+in this document. Recent commits:
+
+- `079530e0cc` (2026-08-01) "Win64 bridge backport (#492)" — two real
marshalling
+ bugs fixed in `uno2cpp.cxx` and `cpp2uno.cxx`
+- `a1206e9491` (2026-07-22) "vcl/basic/sfx2/unixODBC: Win64 (x64) source fixes"
+- `9563caa3b3` (2026-08-06) "vcl: fix CPUNAME token for Win64 entrypoint"
+- `b0e683d3c0` "Fix Win64 compatibility issues with the ADO database driver"
+- `4780e0d437` "vcl/win64: link version.lib + set the x64 DLL entry point"
+- `2cc1933ab8` OpenSSL `-x64` library naming
+
+The Win64 MSVC build is someone else's in-flight project. The clang-cl work
should
+be scoped as *riding* that effort, not duplicating it — and the 64-bit
completion
+work should not be charged to this estimate at all.
+
+## What this plan actually has to do
+
+### C1 — Accept clang-cl in configure
+
+`configure.ac:2234` derives `CCNUMVER` by matching the `cl.exe` banner against
+`/Microsoft/ && /..\...\...../`. clang-cl's banner is `clang version 22.x`,
which
+does not match, so `CCNUMVER` comes out empty and the `-ge 001500000000` test
+fails. A clang-cl branch is needed that sets `CCNUMVER`/`COMEX`/`MSVSVER`
+deliberately.
+
+Note the existing logic accepts *any* `cl.exe` ≥ 15.00 and labels it `COMEX=12`
+/ `MSVSVER=2008` / `CVER=M1500`. So the tree is not so much pinned to VS2008 as
+permanently *mislabelled* as VS2008. Decide explicitly what clang-cl should
report
+rather than inheriting that by accident — the same class of hazard as `B5a` in
the
+MSYS2 document, and worth resolving once for both compilers.
+
+**Effort: 1–2 weeks.**
+
+### C2 — MSYS2 as the shell, replacing Cygwin
+
+Unchanged from `B5` of the MSYS2 plan, and the bulk of this project:
+
+- `configure.ac:1076`, `1146`, `2274` key Windows detection on `build_os`
matching
+ `cygwin`; MSYS2's `config.guess` says `x86_64-pc-msys`.
+- `cygpath` exists in MSYS2 but with different translation semantics; every
call
+ site in `set_soenv.in` and the installer Perl modules needs checking.
+- `configure.ac:6037` demands the Cygwin build of Info-ZIP `zip.exe`.
+- `solenv/bin/guw.pl` — the Unix-path wrapper for MSVC tools — becomes *load
+ bearing* here rather than irrelevant, since we are still driving MSVC tools
from
+ a Unix-ish shell. This is the one place where the clang-cl plan has more work
+ than the GNU-ABI plan.
+- `dmake` builds from source under MSYS2.
+
+**Effort: 3–5 weeks.**
+
+### C3 — clang-cl flag compatibility audit
+
+`solenv/gbuild/platform/windows.mk` sets `gb_CC := cl` / `gb_CXX := cl`, and
+`wntmscx.mk` sets `CC*:=cl` / `CXX*:=cl`. Both need a clang-cl selection.
+
+clang-cl accepts most `cl` flags but not all, and silently ignores some it
does not
+implement. The tree's flag set has to be audited once against clang-cl, in
both the
+dmake makefiles and the gbuild platform file. Warning-suppression pragmas
+(`#pragma warning`) largely carry over; `/analyze` and LTCG-style options do
not.
+
+**Effort: 2–4 weeks, mostly mechanical but broad.**
+
+### C4 — Assembler
+
+`Library_cpp_uno.mk` assembles `call.asm` through gbuild's `gb_AS` with
`-safeseh
+-Cp`. `-safeseh` is x86-only and must not be passed for x64; confirm the x64
path
+sets `ml64` and drops it.
+
+Separately, `solenv/inc/wntmscx.mk:32-33` still says `ASM=ml` with `AFLAGS=/c
/Cp
+/coff` — 32-bit settings in the 64-bit platform makefile. The bridge does not
go
+through this path (it is gbuild), so this may be dead, but it is a live trap
for
+any dmake module that assembles.
+
+**Effort: a few days.**
+
+### C5 — cli_ure
+
+Unchanged and unavoidable: `/clr` is MSVC-only, clang-cl cannot compile
C++/CLI.
+Already gated `w,vc7` in `cli_ure/prj/build.lst`. Under clang-cl the gate needs
+checking, since `COM` stays `MSC` here rather than becoming `GCC` — so the
+mechanism that self-excludes it in the MSYS2 plan **does not apply**, and
+`cli_ure` may try to build and fail. Needs an explicit exclusion.
+
+**Effort: a few days. Flagged because it is easy to miss.**
+
+## What this plan gives up
+
+### System libraries — the `--with-system-*` win does not carry over
+
+This is the significant cost, and it is not obvious.
+
+MSYS2's `mingw-w64-clang-x86_64-*` packages are built for the **GNU ABI against
+the mingw runtime**. An MSVC-ABI build cannot consume them:
+
+- C++ libraries (boost, icu, hunspell, mdds, graphite) — impossible; different
C++
+ ABI, different name mangling, different `std::`.
+- C libraries (zlib, expat, curl, openssl, libxml2) — theoretically closer
since
+ both can be UCRT-based, but MSYS2 ships `.a`/`.dll.a` import libraries in GNU
+ format rather than MSVC `.lib`, and `link.exe` will not consume them as-is.
+
+So the 24-of-24 result from `msys2-probe.sh` section 8 is **not transferable**.
+This build keeps compiling AOO's bundled externals, exactly as the MSVC build
does
+today. The MSYS2 plan's phase 2 was a simplification; here it is simply absent.
+
+If system libraries are wanted later, **vcpkg** is the MSVC-ABI equivalent and
+would be the thing to evaluate — a separate question, not a blocker.
+
+MSYS2's role in this plan is therefore narrower than the name suggests: it
supplies
+the **shell, perl, make, autotools, and dmake host environment**, replacing
Cygwin.
+That is still worth doing, but it is a host-environment modernisation, not a
+dependency reduction.
+
+### Microsoft dependency
+
+Permanent and larger than the GNU-ABI plan's. Requires VS Build Tools (compiler
+headers, CRT, STL, ATL, `ml64`, `link`, `lib`, `midl`) plus the Windows SDK.
The
+"no Visual Studio at all" property of the MSYS2 plan is given up deliberately —
+which is the trade you have accepted.
+
+Still a large improvement on the status quo: Build Tools is a versioned,
+scriptable, IDE-free component that tracks current, versus a pinned VS2008.
+
+## Open questions the tree cannot answer
+
+These need measuring on the Windows machine, in the spirit of `msys2-probe.sh`:
+
+1. **Which clang-cl?** VS Build Tools ships one as the optional "C++ Clang
tools
+ for Windows" component; LLVM's own Windows installer ships another. MSYS2's
+ CLANG64 clang is *not* usable — it targets the GNU triple. Determine which
is
+ present and which is intended.
+2. **Does clang-cl compile ATL?** Expected yes, since clang-cl provides
`_M_X64`
+ and uses MSVC's headers and STL — i.e. every layer that failed in the
GNU-ABI
+ probe is satisfied here. Should be confirmed rather than assumed; it is the
+ premise of deleting the de-ATL port.
+3. **Does `atls.lib` link under clang-cl?** Same ABI, so expected yes.
+4. **`ml64.exe` and `midl.exe` present** in a Build Tools install without the
IDE.
+5. **How far does `--enable-win64` actually get** with plain `cl.exe` today?
This
+ sets the true starting line, and it belongs to the in-flight Win64 effort
rather
+ than to this plan.
+6. **Does clang-cl accept the tree's flag set** — the C3 audit, cheapest to
start
+ empirically on one module.
+
+## Phasing and effort
+
+| Phase | Content | Effort |
+|---|---|---|
+| C1 | clang-cl detection in configure; `CCNUMVER`/`COMEX` decision | 1–2
weeks |
+| C2 | MSYS2 host environment replacing Cygwin; `guw.pl` path handling | 3–5
weeks |
+| C3 | clang-cl flag audit across gbuild + dmake | 2–4 weeks |
+| C4 | Assembler settings for x64 | ~3 days |
+| C5 | `cli_ure` exclusion under `COM=MSC` + clang-cl | ~3 days |
+
+**Roughly 1.5–3 person-months**, *excluding* completion of the 64-bit Windows
port
+itself, which is already in progress independently.
+
+## How this compares
+
+| | MSYS2 / GNU ABI | clang-cl / MSVC ABI |
+|---|---|---|
+| Effort | 5–9 person-months | 1.5–3 person-months |
+| Hard blocker | New Win64 UNO bridge (6–10 wks) | None |
+| ATL | De-ATL port required (measured) | Works as-is |
+| System libraries | 24/24 from MSYS2 | None; bundled builds stay |
+| Microsoft dependency | Windows SDK only | VS Build Tools + SDK |
+| Toolchain currency | Rolling, self-updating | Versioned, IDE-free, current |
+| `cli_ure` | Excluded | Excluded |
+
+The two are not mutually exclusive. C1–C3 move the tree toward a Unix-shell,
+modern-compiler Windows build regardless of ABI, and most of C2 is shared with
the
+MSYS2 plan's `B5`. Doing clang-cl first would leave the GNU-ABI option open at
+lower cost later, having already retired the host-environment work.
+
+## Verified versus asserted
+
+Verified by inspection of this tree at the line numbers cited: the
`--enable-win64`
+switch and `BUILD_WIN64` plumbing; the `set_soenv.in` Windows CPU/OUTPATH
block;
+the `wnt.mk` `WNTMSCX` dispatch; the `WNT-X86_64-mscx` bridge branch and its
file
+list; the `cl.exe` banner parsing and the `COMEX=12` labelling of every
compiler
+≥ 15.00; `gb_CC`/`gb_CXX` being literal `cl`; the `-safeseh -Cp` assembler
command;
+the 32-bit `ASM=ml`/`/coff` settings in `wntmscx.mk`; `set_wntx64.mk` being
used
+only by `shell/`; and the Win64 commit history cited above.
+
+Asserted, **not** verified:
+
+- That clang-cl compiles ATL and links `atls.lib`. Strongly expected — it is
the
+ MSVC ABI with MSVC's headers — but it is the premise on which the de-ATL
saving
+ rests, and it deserves the same probe treatment that overturned the SDK-ATL
+ assumption.
+- That clang-cl accepts substantially all of the tree's `cl` flags.
+- That MSYS2's GNU-format import libraries cannot be linked by `link.exe`.
This is
+ the basis for writing off the `--with-system-*` win; it follows from how the
two
+ toolchains differ, but was not tested.
+- The effort figures. They are judgement, calibrated against the MSYS2
document's
+ own scale, not measurements.
