[FFmpeg-devel] Consider using CMake.

[FFmpeg-devel] Consider using CMake.

[crueter via ffmpeg-devel]

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 -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Consider using CMake.

[Timo Rothenpieler via ffmpeg-devel]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 449 bytes --]

That's very unlikely to happen.
The current scripts support building using msvc just fine.
Porting everything to any other build system without causing an endless 
slew of regressions and dropping support for a ton of targets is 
virtually impossible.

Just open a MSVC command prompt, launch C:/MSYS64/msys2.exe (or wherever 
you installed it) or if you got it set up wsl.exe, run ./configure 
--toolchain=msvc and build away.



Timo

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3203 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

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

[FFmpeg-devel] Re: Consider using CMake.

[swurl via ffmpeg-devel]

"MSVC works fine! Just go to MSYS2 first"

That isn't "working", that's a horrible workaround. Not to mention this 
is a nightmare to script or run in a CI environment.

Again, *I have tried this and it isn't good.* It's very prone to 
breaking and pretty much impossible to make any meaningful changes. Not 
to mention it almost never works

 > Porting everything to any other build system without causing an 
endless slew of regressions and dropping support for a ton of targets is 
virtually impossible.

Call me crazy but I don't think FFmpeg needs to support somebody's 2003 
toaster running a 200 MHz POWER4. Everything else is trivial to keep 
support for, because *CMake literally runs everywhere.* See 
https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html.

On 1/23/26 9:49 PM, Timo Rothenpieler via ffmpeg-devel wrote:
> That's very unlikely to happen.
> The current scripts support building using msvc just fine.
> Porting everything to any other build system without causing an 
> endless slew of regressions and dropping support for a ton of targets 
> is virtually impossible.
>
> Just open a MSVC command prompt, launch C:/MSYS64/msys2.exe (or 
> wherever you installed it) or if you got it set up wsl.exe, run 
> ./configure --toolchain=msvc and build away.
>
>
>
> Timo
>
> _______________________________________________
> ffmpeg-devel mailing list --ffmpeg-devel@ffmpeg.org
> To unsubscribe send an email toffmpeg-devel-leave@ffmpeg.org
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Consider using CMake.

[Rémi Denis-Courmont via ffmpeg-devel]

Le lauantaina 24. tammikuuta 2026, 0.47.34 Itä-Euroopan normaaliaika crueter 
via ffmpeg-devel a écrit :
> 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.

There are zero chances of that happening.

If a transition happens, it would presumably be towards Meson, which is way 
more suited. But even that's a long shot.

-- 
ヅニ-クーモン・レミ
https://www.remlab.net/



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

[FFmpeg-devel] Re: Consider using CMake.

[crueter via ffmpeg-devel]

Meson is even slower than the horribly written configure script AND has a hard dependency on Python. Absolutely not.


-------- Original Message --------
From: "Rémi Denis-Courmont via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>
Sent: January 24, 2026 5:14:48 AM EST
To: ffmpeg-devel@ffmpeg.org
Cc: "Rémi Denis-Courmont" <remi@remlab.net>
Subject: [FFmpeg-devel] Re: Consider using CMake.

Le lauantaina 24. tammikuuta 2026, 0.47.34 Itä-Euroopan normaaliaika crueter 
via ffmpeg-devel a écrit :
> 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.

There are zero chances of that happening.

If a transition happens, it would presumably be towards Meson, which is way 
more suited. But even that's a long shot.

-- 
ヅニ-クーモン・レミ
https://www.remlab.net/



_______________________________________________
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

[FFmpeg-devel] Re: Consider using CMake.

[James Almer via ffmpeg-devel]

[-- Attachment #1.1.1: Type: text/plain, Size: 1917 bytes --]

On 1/23/2026 7:47 PM, crueter via ffmpeg-devel 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.

I'm fairly sure you're required to use an environment like Msys2 to 
compile FFmpeg. Looking at 
https://fate.ffmpeg.org/report.cgi?slot=amd64-msvc&time=20260123104905 i 
see compiling statically with msvc is not a problem.
The configure script has plenty of msvc specific considerations. You may 
have forgotten to to pass --toolchain=msvc to it.

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

Every package we check for with pkg-config will have a .pc file on a 
Windows install as it will on a Linux one. But i suspect quite a few 
will require you to build them with mingw-w64, though.

Keep in mind that pkg-config requires you to pass --static to get the 
proper command line arguments to link to dependencies statically. In the 
context of ffmpeg configure, that'd be done with 
--pkg-config-flags="--static".


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

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

[FFmpeg-devel] Re: Consider using CMake.

[Timo Rothenpieler via ffmpeg-devel]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1001 bytes --]

On 24.01.2026 03:57, swurl via ffmpeg-devel wrote:
> "MSVC works fine! Just go to MSYS2 first"
> 
> That isn't "working", that's a horrible workaround. Not to mention this 
> is a nightmare to script or run in a CI environment.
> 
> Again, *I have tried this and it isn't good.* It's very prone to 
> breaking and pretty much impossible to make any meaningful changes. Not 
> to mention it almost never works

It works perfectly fine for me.

>  > Porting everything to any other build system without causing an 
> endless slew of regressions and dropping support for a ton of targets is 
> virtually impossible.
> 
> Call me crazy but I don't think FFmpeg needs to support somebody's 2003 
> toaster running a 200 MHz POWER4. Everything else is trivial to keep 
> support for, because *CMake literally runs everywhere.* See https:// 
> cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html.

Just because you don't care about it doesn't mean other people also don't.


[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3203 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

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

[FFmpeg-devel] Re: Consider using CMake.

[Rémi Denis-Courmont via ffmpeg-devel]

Le lauantaina 24. tammikuuta 2026, 14.32.39 Itä-Euroopan normaaliaika crueter 
via ffmpeg-devel a écrit :
> Meson is even slower than the horribly written configure script AND has a
> hard dependency on Python. Absolutely not.

Ultimately you're free to port the FFmpeg build system to CMake yourself (or 
pay someone to do so), and submit a PR showing how so much better it actually 
is. Just don't be surprised if people reject it on the basis that it does not 
work or is no better, or even actually worse, for most purposes other than 
building FFmpeg on MSVC.

By the way, that includes building FFmpeg for Windows with an actual C/C++ 
toolchain (MingW or LLVM/Clang) from Linux or WSL, rather than using a sorry 
approximation of one such as MSVC.

However your phrasing seems to indicate that you have no intention of actually 
conducting that work. So then, there is no point in continuing this 
discussion, because nobody else is going to try to do such it either.

-- 
Rémi Denis-Courmont
https://www.remlab.net/



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

[FFmpeg-devel] Re: Consider using CMake.

[Zhao Zhili via ffmpeg-devel]

> 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

[FFmpeg-devel] Re: Consider using CMake.

[crueter via ffmpeg-devel]

Yeah and those people don't matter. Anyways, this mailing list is a disaster. 


-------- Original Message --------
From: Timo Rothenpieler via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
Sent: January 24, 2026 11:06:28 AM EST
To: ffmpeg-devel@ffmpeg.org
Cc: Timo Rothenpieler <timo@rothenpieler.org>
Subject: [FFmpeg-devel] Re: Consider using CMake.

On 24.01.2026 03:57, swurl via ffmpeg-devel wrote:
> "MSVC works fine! Just go to MSYS2 first"
> 
> That isn't "working", that's a horrible workaround. Not to mention this is a nightmare to script or run in a CI environment.
> 
> Again, *I have tried this and it isn't good.* It's very prone to breaking and pretty much impossible to make any meaningful changes. Not to mention it almost never works

It works perfectly fine for me.

>  > Porting everything to any other build system without causing an endless slew of regressions and dropping support for a ton of targets is virtually impossible.
> 
> Call me crazy but I don't think FFmpeg needs to support somebody's 2003 toaster running a 200 MHz POWER4. Everything else is trivial to keep support for, because *CMake literally runs everywhere.* See https:// cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html.

Just because you don't care about it doesn't mean other people also don't.

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

[FFmpeg-devel] Re: Consider using CMake.

[swurl via ffmpeg-devel]

I probably should have expected stuck-up retards like you to immediately 
complain about "just do it yourself harr harr harr". I specifically 
created this to serve as a discussion piece, not for some 50 year old 
corporate slave to immediately start hurling cope at me.

I actually did plan to port it eventually, but now I don't really feel 
like doing it anymore because of your incredibly dismissive attitude 
towards the mere thought of someone making an objectively good change. 
Maybe I'll do it someday but add a clause to the license stating that 
you must not be named Rémi Denis-Courmont to use this. :)

 > rather than using a sorry approximation of one such as MSVC.

Again, unnecessarily dismissive. There are a huge number of use cases 
for MSVC, because it is by far the most used compiler for desktop 
targets. Do note that MinGW-built static libraries are not compatible 
with MSVC executables.

On 1/24/26 11:13 AM, Rémi Denis-Courmont via ffmpeg-devel wrote:
> Le lauantaina 24. tammikuuta 2026, 14.32.39 Itä-Euroopan normaaliaika crueter
> via ffmpeg-devel a écrit :
>> Meson is even slower than the horribly written configure script AND has a
>> hard dependency on Python. Absolutely not.
> Ultimately you're free to port the FFmpeg build system to CMake yourself (or
> pay someone to do so), and submit a PR showing how so much better it actually
> is. Just don't be surprised if people reject it on the basis that it does not
> work or is no better, or even actually worse, for most purposes other than
> building FFmpeg on MSVC.
>
> By the way, that includes building FFmpeg for Windows with an actual C/C++
> toolchain (MingW or LLVM/Clang) from Linux or WSL, rather than using a sorry
> approximation of one such as MSVC.
>
> However your phrasing seems to indicate that you have no intention of actually
> conducting that work. So then, there is no point in continuing this
> discussion, because nobody else is going to try to do such it either.
>
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Consider using CMake.

[Rémi Denis-Courmont via ffmpeg-devel]

Your original mail sounded more like a demand than an offer. Are we supposed to infer that you don't really master the English language?

Thing is, even if you don't, public insult and defamation are felonies, not technical arguments. Also they make you look very immature, dumb and ignorant of open-source.

So congrats on ruining your own arguments, I guess.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: Consider using CMake.

[ff--- via ffmpeg-devel]

On 2026-01-25 12:30, Rémi Denis-Courmont via ffmpeg-devel wrote:
> defamation

hey, as long as we are on the subject...

are you out there saying i was banned from something? i dont recall any 
notification stating i was banned from anything.

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