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

["softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: Kacper Michajlow <kasper93@gmail.com>
> Sent: Tuesday, June 17, 2025 6:36 PM
> To: softworkz . <softworkz@hotmail.com>
> Cc: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: graph.{html,css} embed failure on Windows build

[..]

> > > > I will wait for the remaining CI builds to succeed and submit the
> > > > rebased patchset to the ML then.
> > > >
> > > > Please let me know whether it fixes the build on your side as well.
> > >
> > > Yes, this fixes the build issue. Thanks.
> >
> > Thanks for confirming. Patch update sent.
> >
> > > Note, I created a pipeline to upload this failing configuration to the fate
> server.
> > > So we have coverage of this config now. Things tend to break if
> > > something is not tested.
> >
> > Yup - but that's testing only after merge to master.
> > I'm thinking about adding an additional check build for Patchwork.
> > Do you think your configuration is common enough to do this? Or is
> > there a more typical configure setup for this kind of build
> > (Win-CLang) that would make more sense for the project?
> 
> I think this config is criminally underused. Everyone thinks MSVC
> (cl.exe) only when talking about Visual Studio. But actually they are shipping
> LLVM toolchain which is a great way to build software with Windows SDK
> (without mingw) that is not MSVC (cl.exe) compatible.

It still needs MSYS2 for the Gnu build system, but yea, I get the point of 
using the platform SDK directly.
How's the resulting binaries' performance? I'm using the SMP project 
generator which allows you to actually work and debug in VS like with
any other MSVC project/solution, but for production compiles, that's 
not an option as it's way slower than the GCC/MSYS2/mingw path..


> Of course mingw and
> llvm-mingw have existed for a long time and are goto solutions for such cases,
> but I find it nice to run software with standard SDK.
> 
> To answer your questions, depends how much resources you want to throw at
> that. I wouldn't say this configuration is critical. Though at least one Clang
> based Windows build would be good to have, whether llvm-mingw or clang-
> msvc. Note I don't mean clang-cl because this thing is supposed to be closely
> compatible with MSVC itself, so in theory if cl.exe is working clang-cl.exe
> should do too.

Now that andriy/make_x86 is active again, I can disable softworkz/make_linux_x64,
which is almost the same. The mac run is the fastest and of no concern, Linux-shared
and Linux-out-of-tree don't run FATE. The heavy-weights are Win-MSVC and Win-GCC
which take 40-60 and 30-50 minutes including FATE (but only partial FATE due to
the pending patchset for subtitle refs). The Win-MSVC-CLang took 50min (but I don't
know the range yet).

FATE takes about 2/3 of the time, so when adding Win-MSVC-CLang it would be good
to have at most 2 of the - then 3 - Windows builds also running FATE. I'm not sure
which of them would be the least important - maybe Win-GCC, because it's closest
to the Linux FATE build and Windows-specific issues would be detected with Win-MSVC
and Win-MSVC-CLang anyway?

Thanks,
sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".