> -----Original Message-----
> From: Kacper Michajlow <kaspe...@gmail.com>
> Sent: Tuesday, June 17, 2025 6:36 PM
> To: softworkz . <softwo...@hotmail.com>
> Cc: FFmpeg development discussions and patches <ffmpeg-
> de...@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-requ...@ffmpeg.org with subject "unsubscribe".
