> On Jan 24, 2026, at 06:47, crueter via ffmpeg-devel <[email protected]> > wrote: > > Recently, I've been attempting to get FFmpeg building on MSVC. Normally > FFmpeg is built with MinGW for Windows, but it is 100% possible to build it > on MSVC. For those curious, I need this as a *static* library, and attempting > to link statically built MinGW libraries on MSVC generally doesn't make for a > fun time. > > However, previously I had to rely on several horrible hacks, such as running > everything through the MSYS shell (not ideal in the slightest), and then > manually implanting `cl.exe` and others into PATH. This is not only a huge > pain, but actually caused significant problems as it made it much harder to > make pretty much any changes whatsoever without inevitably breaking > everything. > > Thus, when I had to make some significant changes to my script, I ended up > facing a large number of issues. In no particular order: > > * pkg-config is basically nonexistent on Windows, and is barely > functional when it does exist. This was a problem for Vulkan, > ffnvcodec, openssl, and others. > * Some of the libraries spit out absolutely gargantuan commands that > go well over Windows' command line character limit of 8191, causing > indecipherable build failures. > * Windows' pathing is fundamentally incompatible with UNIX pathing, > which caused also indecipherable build failures that ended up being > caused by `gsub` in one of the scripts. Notably, I had to use this > awful hack: > sed-i's|gsub(/\\\\|gsub(/\\\\\\\\|g'ffbuild/*.mak > > * After all of this, I still haven't managed to get it to build, > because I STILL get completely random build failures that make no > sense whatsoever. For example, the libavutil target sometimes simply > refuses to build any of its associated object files: LINK : fatal > error LNK1181: cannot open input file 'libavutil\adler32.o' I still > haven't figured this one out. It requires manual intervention to > fix, which is terrible for UX and also virtually impossible to script.
Parts of these issues are true. 1. FFmpeg can be build with MSVC, but configure takes a few minutes on a decent machine in msys2. wm4 filed a issue to microsoft https://github.com/microsoft/Windows-Dev-Performance/issues/15 2. Shell script in WSL is fast, but IO between WSL and Windows host is terrible. 3. Manage third party dependencies with MSVC toolchain is worse. Something mismatch like this: pkg-config gives -lfoo, but MSVC search for foo.lib than libfoo.a gstreamer has a meson ports of ffmpeg: https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg.git From my tests, it takes 63 seconds for meson setup, while shell script configure takes 333 seconds. ``` $ time meson setup \ -Dprograms=enabled \ -Dnonfree=enabled \ meson-build ... Found ninja-1.11.1 at D:\bin\msys\ucrt64\bin/ninja.EXE real 1m2.820s user 0m0.015s sys 0m0.000s ``` ``` $ time ../configure --toolchain=msvc --target-os=win64 real 5m33.280s user 0m1.272s sys 0m1.510s ``` The same machine takes 10 seconds to run configure on Linux. That's how painful to work on Windows with shell script.  > > My proposition to solve this is to use CMake. The great thing about CMake is > that *we don't have to worry about any of this!* CMake is incredibly smart > and is more than capable of doing all of that and more, and *dramatically* > faster too. It has so many advantages that I can't list them all. But here's > an abridged list: > > * CMake is completely platform agnostic and doesn't require a "special > GNU build" like make does. Instead it's capable of using Ninja, also > platform agnostic, which is both faster than make AND runs > everywhere. This would've fixed several of the Windows-specific > issues I faced--not to mention that users of non-GNU operating > systems (Solaris, *BSD, etc.) don't HAVE to install GNU make just > for it to work. This also means those users don't have to explicitly > invoke `gmake` and can instead just `cmake --build`. > * CMake does a lot for you. The giant-wall-of-text configure script is > cool and all, but CMake requires significantly less manual > intervention, as it handles: > o Compilers > o Build type > o Options and settings > o Platform/architecture specific stuff > * CMake doesn't rely on coreutils or anything besides itself. This > means you don't *have* to install GNU coreutils on systems that lack > them by default, and also prevents spurious failures caused by minor > differences between distributions of awk, sed, etc. > * CMake handles package finding for you. Many of FFmpeg's dependencies > *also* install CMake config files, which are significantly nicer to > play with than pkg-config. CMake is also perfectly capable of using > pkg-config as well! > * CMake scripts are FAR more readable. Trying to parse through the > giant configure script is a pain, especially when I'm trying to see > what an option does and leaving confused because it's handled in > some random other file nobody has touched in 10 years. With CMake > however, options are laid out nicely in explicit commands and can > even be parsed by IDEs, making them extremely easy to read and find. > > This isn't even close to a comprehensive list of CMake's benefits nor the > MANY problems I had with the configure script. That being said, I imagine > this will be met with a lot of criticism, so to pre-emptively answer some > questions I may or may not receive: > > * *Why not do it yourself?* > o The biggest reason is I don't fully understand what every option > does and thus would not be able to do much of anything helpful. > Not to mention I don't really have the free time at the moment > to dive into something that may very well be immediately > rejected from the patch mailing list. > * *Why not just fix the configure script and Makefiles?* > o This is an even bigger ask than making a whole new build system, > because it is fundamentally not designed for MSVC to even be > possible whatsoever. Makefiles are inherently UNIX-y and don't > play well with Windows in general; not to mention that > maintaining a giant wall of text script is generally frowned upon. > * *Why change what's not broken?* > o The build system as is, is quite broken on MSVC. I barely > scratched the surface of the sheer myriad of issues I had and am > still having. > > That's all. > _______________________________________________ > ffmpeg-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
