Hey $list, not an FFmpeg developer, but I worked on the meson port and figured I could address some of the points that were made.
Since the initial post I have also added support for compiling with Msys/MingW on Window now in addition to MSVC. ## Performance comparison A significant part of the discussion has focused on the configure script being slow, often in a hard-to-predict manner. My findings confirm that: | Method | Linux | Windows (msys-2 / mingw64) | MacOS high sierra | | ----------- | -------------- | -------------------------- | ----------------- | | meson | 16s | 1m 2s | 25s | | ./configure | 1m 21s (506 %) | 13m 5s (1266 %) | 4m 20s (1040 %) | I have no doubt the configure script could be optimized further, but it is obviously a pretty complex piece of code, where a meson port would have the advantage of shifting the burden of optimization to the meson development team, see https://github.com/mesonbuild/meson/issues/3635 for example. The other question is if anyone is actually willing to work on optimising the configure script, because if not it's a bit of a moot point. And it would have to be optimised a lot to make it somewhat bearable on Windows again. Profiling meson is also probably much easier than profiling the configure script, I noticed one developer reporting their initial attempt at doing so resulted in a window manager crash. On the other hand, meson recently added native support for self-profiling, using the `--profile-self` switch to trigger the creation of a profile graph. It should be noted that build time does *not* seem to be any different with meson or make, as FFmpeg's build is already well parallelized. ## Meson development practices While meson is indeed a relatively new project, it has been adopted by many projects, GNOME being a prominent one, but neither an early one nor the only one. It is neither a GNOME project nor a freedesktop project, you can find a (non-exhaustive) list of users at http://mesonbuild.com/Users.html. It has been adopted for example by xorg, wayland, mesa, and VLC could as far as I understand soon be added to that list as well. It has a policy of no regressions, and an extensive test suite to ensure that. ## The port currently depends on meson master I did debate waiting for a new meson release before publishing my work, but (perhaps impatiently) decided against it. The meson port currently depends on two features I added in meson for FFmpeg specifically: * A new dictionary built-in type (https://github.com/mesonbuild/meson/pull/3490) * Native support for generating asm config files (https://github.com/mesonbuild/meson/pull/3636) While I see how this can be used as an argument against the meson port, my view on that is a bit different, as I think it shows meson's development team welcomes new features, provided a good case is made for them. Meson is usable directly from a git checkout, I figured it was a reasonably low barrier to testing what is still obviously a semi-experimental port. In any case, all the improvements that were made to meson for the FFmpeg use case are now part of the latest release, 0.47 (https://mesonbuild.com/Release-notes-for-0-47-0.html) which can easily be installed using pip3 if you are not on a distro that has the latest release. ## Duplicate maintenance burden That is a very valid point, which an outsider to the project cannot really argue with. What I can say is that I will be happy to assist with improving and maintaining the port should the community decide that it would be a valuable addition, and I am sure I would not be the only one with an interest in keeping the Meson port up-to-date. Anyone developing on Windows would likely appreciate it, and any projects that depend on FFMpeg and use meson themselves as their build system would be able to use the latest FFmpeg as a meson subproject should they wish to do so instead of using the system-installed version. ## Points I have not seen discussed While configure-time performance improvements are a clear advantage, I think the main reasons a port to meson could prove useful in the long term are maintainability and accessibility. I think it is likely that newcomers to FFmpeg development find contributing to the configure script a bit daunting, and that even long-time FFmpeg developers must sometimes have a hard time with it. On the other hand, my experience with meson is that it tends to help with writing readable and elegant build definitions, I can't think of another build system that does a better job at that. If there are any other questions related to meson or the FFmpeg meson port please feel free to ask and I'll do my best to answer them. -- Mathieu _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel