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.
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]
