[FFmpeg-devel] graph.{html,css} embed failure on Windows build

[Kacper Michajlow]

On Tue, 17 Jun 2025 at 04:07, softworkz . <softworkz at hotmail.com> wrote:
>
>
> > -----Original Message-----
> > From: Kacper Michajlow <kasper93 at gmail.com>
> > Sent: Sunday, June 15, 2025 12:49 AM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Cc: softworkz at hotmail.com
> > Subject: graph.{html,css} embed failure on Windows build
> >
> > Hello,
> >
> > Since the recent addition of resman.c and embedding of graph.{html,css}
> > some of the Windows builds fail. There seems to be a regression in path
> > joining, caused by \ / mismatch.
> >
> > Generally those issues were never a problem and I would prefer to keep it this
> > way. This configuration has always been flaky and undertested.
> > I could set-up a pipeline to report to the fate server if that's something that
> > would help stabilize it.
> >
> > Example of failure:
> > ```
> > BIN2C fftoolsresourcesgraph.html.c
> > BIN2C fftools/resources/graph.html.c
> > SED fftoolsresourcesgraph.css.min
> > sed: can't read /c/a/FFmpeg/FFmpeg/fftoolsresources/graph.css: No such file
> > or directory SED fftools/resources/graph.css.min
> > make: *** No rule to make target 'fftools\resources\graph.html.c', needed by
> > 'fftools/resources/graph.html.o'. Stop.
> > make: *** Waiting for unfinished jobs....
> > HOSTCC tests/videogen.o
> > rm fftools\resources\graph.css.min fftools/resources/graph.html.c ```
> >
> > Note that BIN2C is called twice, once with the correct path and with the
> > wrong one.
> >
> > Removing resman.c fixes the build. This has to be done forcefully in the code,
> > because there is no configure option to disable this html/css embedding.
> >
> > You can see the details and whole failing build logs here:
> > code: https://github.com/kasper93/FFmpeg/tree/gha
> > build:
> > https://github.com/kasper93/FFmpeg/actions/runs/15653223193/job/44100
> > 735119
> > command: $ ../configure --enable-gpl --enable-version3 --enable-nonfree --
> > samples=../samples --enable-memory-poisoning
> > --arch=amd64 --enable-w32threads --as=clang --ar=llvm-ar --cxx=clang++ --
> > ld=lld-link --windres=llvm-windres --strip=llvm-strip --cc=clang --nm=llvm-nm
> > --extra-ldflags='msvcrt.lib oldnames.lib'
> > --host_extralibs='' --toolchain=msvc && make -j`nproc` && make -j`nproc`
> > run-checkasm && make -j`nproc` fate-rsync && make -j`nproc` fate
> >
> > Here is exactly the same pipeline with removed graph.{html,css}
> > https://github.com/kasper93/FFmpeg/tree/gha2
> > https://github.com/kasper93/FFmpeg/actions/runs/15656127992
> > Builds just fine.
> > Ignore win32 (windows-11-arm, arm64, --toolchain=msvc) failure, as this is
> > affected by unrelated regression in dxvenc.c on arm64 target, but the build
> > itself is passing just fine.
> >
> > Any ideas how we can restore the ability to build ffmpeg on Windows?
>
> Hi Kasper,
>
> I was able to reproduce the issue by adding a new CI build (for PRs to
> ffstaging/ffmpeg (on GitHub, not yet for Patchwork).
>
> It appears to be all about dir separators when building under MSYS2 with
> Clang. Clang insists on using backslashes (unlike GCC and MSVC) and that
> screws the Gnu make logic (pattern rules, dependency and up-to-date
> checks).

Why is Clang involved in .css conversion rules? It seems to fail at
the `%.css.min: %.css` rule already, which shouldn't involve any C
toolchain related bits. Is this propagated from the .o file? In which
case why does the .o have "wrong" path separators?

Isn't there an issue in vpath? Maybe we can make it somehow proper
separators. Few days I briefly looked at this, but it wasn't obvious
what would be the correct solution here. Changing vpath to extract
only files in fftools/resources was improving things, but still not
fully.

Also vpath in fftools/resources/Makefile is setting search path in the
whole SRC_PATH, while imho it should be restricted to the
fftools/resources directory only.

- Kacper