Repository navigation
ci(windows): install winflexbison3 for the amd-mesa flex/bison dependency - #10951
Conversation
…ex/bison dependency Signed-off-by: Daniel Olsson <Daniel.Olsson@amd.com>
✅ All Policy Checks Passed
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
Will merge given approvals and goal to fix forward previously found build failures:
It seems it could be related to this particular runner https://github.com/ROCm/rocm-systems/actions/runs/33374472878/job/99433063145?pr=10951#step:10:79 CPU: AMD EPYC 7452 32-Core Processor (AMD64)
Logical cores: 96
GPU: GPU 0: None
RAM: Total Physical Memory: 383.99 GB
Avail Physical Memory: 368.29 GB
Avail Virtual Memory: 408.54 GB
STORAGE: Disk Total Space: 419.45 GB
Disk Avail Space: 362.95 GB
Disk Used Space: 56.5 GB
Disk Usage: 13.47 %
I reran to see that it builds successfully and no longer fails at flatten split artifacts for windows, and other tests are unrelated. |
TheRock Submodule Bump ActivityNewest first
|
Motivation
The Windows build jobs fail while Meson configures the
therock-amd-mesasysdep,because neither
flexnorbisonis present on the runner:Mesa's Meson build generates its lexer/parser sources at configure time, so without
those two programs it cannot produce them and the build stops before compiling
anything. Every Windows build job dies here, which blocks unrelated PRs from ever
reaching their Windows test stages.
Technical Details
Root cause is a gap in the Windows "Install requirements" step: it installs
ccache,ninja,strawberryperl,awscliandpkgconfiglitevia Chocolatey, but not thepackage providing
flex/bison. This change addswinflexbison3alongside them,using the same
--no-progress -yflags as the surrounding invocations.winflexbison3is the standard Windows port and installs bothwin_flexandwin_bison; Meson'sflex lexlookup resolves against it. TheRock's own Windowsworkflow already installs this package for the same reason, so this brings the
rocm-systems workflow in line rather than inventing a new approach.
Scope is deliberately limited to the CI workflow — no build sources, CMake, or
project code are touched.
Risk: low. A single added package install on the Windows CI image; it cannot affect
Linux jobs or any build output, and the worst case is an unused package.
Issue Tracking
JIRA ID: ROCM-30032
Test Plan
CI-driven, since the change only takes effect on the CI runner. Opening this as a
normal (non-draft) PR runs the full Windows build including gfx1151, which is the
job that currently fails at the mesa configure step.
Pass criteria: the Windows build proceeds past
third-party/sysdeps/windows/amd-mesawithout the
Program 'flex lex' not founderror.Test Result
Pending CI on this PR.
Submission Checklist