[FFmpeg-devel] [RFC] New build system

[Mathieu Duponchelle]

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