Jens-G opened a new pull request, #3908: URL: https://github.com/apache/thrift/pull/3908
Cuts the AppVeyor build matrix from six jobs to three and lets the remaining jobs build in parallel. Measured on build [0.26.0.10733](https://ci.appveyor.com/project/ApacheSoftwareFoundation/thrift/builds/54753905) and cross-checked against 0.26.0.10724, a different pull request with near-identical timings. **Five of the six jobs were the same build.** They differed only in `PYTHON_VERSION`, 3.10 through 3.14. Each one built the whole C++ library, the compiler and every test executable — 21 min 27 s — so that 12 Python tests could run, 112 s of a 248 s `ctest` run. The other 54 tests are C++ and were identical in all five. That matrix already runs twice in GitHub Actions: `lib-python` on ubuntu-24.04 and `lib-python-macos`, both off the same YAML anchor in `.github/workflows/build.yml`. What the AppVeyor jobs add on top is the MSVC build of the `fastbinary` extension and the Windows behaviour of the pure-Python tests, and neither of those changes between 3.11, 3.12 and 3.13. Kept are the two edges of the range: 3.11, the oldest version still supported upstream once 3.10 reaches end of life on 2026-10-31, and 3.14. The upper edge moves to 3.15 once the AppVeyor image carries it. **Nothing was built in parallel.** `cmake --build` was called without `--parallel` in both scripts, so MSBuild built one project at a time — the log shows some 40 test executables completing in sequence, 3 to 15 s apart — and `mingw32-make` ran single-threaded for 34 min 13 s of that job's 46 min. Both now pass `--parallel %NUMBER_OF_PROCESSORS%`. The explicit number is deliberate. Measured with CMake 3.22 on the Makefile generator: | invocation | resulting MAKEFLAGS | | --- | --- | | `cmake --build .` | `s` (serial) | | `cmake --build . --parallel` | `s -j` (unbounded) | | `cmake --build . --parallel 3` | `s -j3` | A bare `--parallel` would hand the MinGW job an unbounded `make -j`. `win_showenv.bat` now reports `NUMBER_OF_PROCESSORS`. Nothing in the build log said how many cores a worker offers, and that is what decides how much the parallel build can buy. ### Testing The change is CI configuration; the AppVeyor run on this pull request is the test. Worth reading in that run: the reported core count, and whether the MSVC job's build phase drops below its usual ~21 minutes. ### Related - **THRIFT-6325** repairs a CMake quoting bug that keeps `/MP` from ever being applied. Deliberately a separate pull request. MSBuild's `/m` works at project level and `/MP` at source level; the two multiply, and on a small worker they can oversubscribe. Landing them apart gives a clean A/B on the job timings, and a second landing that brings no improvement — or a regression — is the signal to cap `/MP`. - **INFRA-28428** asks for rolling builds on the AppVeyor project. That is the larger half of the problem and this change does not touch it: across the last 23 finished builds the median wait was 6 h 26 min against 1 h 43 min of building, and superseded pull request builds currently run to completion. --- - [x] Did you create an [Apache Jira](https://issues.apache.org/jira/projects/THRIFT/issues/) ticket? — THRIFT-6324 - [x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"? - [x] Did you squash your changes to a single commit? - [x] Did you do your best to avoid breaking changes? Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> -- 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]
