[FFmpeg-devel] Re: Consider using CMake.

[Zhao Zhili via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

> On Jan 24, 2026, at 06:47, crueter via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> 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 -- ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org