[pulseaudio-discuss] [PATCH] build-sys: First pass at a meson-ified build system

Tue Dec 12 04:17:14 UTC 2017

On Tue, 12 Dec 2017, at 07:29 AM, Tanu Kaskinen wrote:
> On Sun, 2017-12-10 at 12:46 +0530, Arun Raghavan wrote:
> > On Sat, 9 Dec 2017, at 10:58 PM, Felipe Sateler wrote:
> > > On Sat, Dec 9, 2017 at 2:59 AM, Arun Raghavan <arun at arunraghavan.net>
> > > wrote:
> > > > (Note: this patch depends on the symdef header removal work from a few
> > > > days ago)
> > > > 
> > > > This is a working implementation of a build with meson. The server,
> > > > utils, and most modules build with this, and it is possible to run from
> > > > a build tree and play/capture audio on ALSA devices.
> > > > 
> > > > There are a number of FIXMEs, of course, and a number of features that
> > > > need to be enabled (modules, dependencies, installation, etc.), but this
> > > > should provide everything we need to get there relatively quickly.
> > > > 
> > > 
> > > This is nice. Build times should be greatly reduced. As a datapoint,
> > > you can check how the systemd debian package takes about hallf the
> > > time since version 234, when meson was introduced.
> > > 
> > > https://buildd.debian.org/status/logs.php?pkg=systemd&arch=amd64&suite=sid
> > > 
> > > > To use this, install meson (distro package, or mesonbuild.com) and run:
> > > > 
> > > >   $ cd <pulseaudio src dir>
> > > >   $ meson <builddir>
> > > >   $ ninja -C <builddir>
> > > > ---
> > > >  meson.build                       | 218 ++++++++++++++++++++++++++++++++++++++
> > > >  meson_options.txt                 |  13 +++
> > > >  src/daemon/daemon-conf.c          |   4 +
> > > >  src/daemon/main.c                 |   9 ++
> > > >  src/daemon/meson.build            |  34 ++++++
> > > >  src/meson.build                   | 194 +++++++++++++++++++++++++++++++++
> > > >  src/modules/alsa/meson.build      |  31 ++++++
> > > >  src/modules/meson.build           | 127 ++++++++++++++++++++++
> > > >  src/modules/module-role-cork.c    |   2 +-
> > > >  src/modules/module-role-ducking.c |   2 +-
> > > >  src/pulse/meson.build             |  73 +++++++++++++
> > > >  src/pulsecore/meson.build         | 170 +++++++++++++++++++++++++++++
> > > >  src/pulsecore/module.c            |   4 +
> > > >  src/utils/meson.build             |  67 ++++++++++++
> > > >  14 files changed, 946 insertions(+), 2 deletions(-)
> > > >  create mode 100644 meson.build
> > > >  create mode 100644 meson_options.txt
> > > >  create mode 100644 src/daemon/meson.build
> > > >  create mode 100644 src/meson.build
> > > >  create mode 100644 src/modules/alsa/meson.build
> > > >  create mode 100644 src/modules/meson.build
> > > >  create mode 100644 src/pulse/meson.build
> > > >  create mode 100644 src/pulsecore/meson.build
> > > >  create mode 100644 src/utils/meson.build
> > > > 
> > > > diff --git a/meson.build b/meson.build
> > > > new file mode 100644
> > > > index 000000000..1b00dc1e0
> > > > --- /dev/null
> > > > +++ b/meson.build
> > > > @@ -0,0 +1,218 @@
> > > > +project('pulseaudio', 'c', 'cpp',
> > > > +        version : '10.99.1',
> > > > +        meson_version : '>= 0.31.0',
> > > > +        default_options : [ 'c_std=gnu11', 'cpp_std=c++11' ]
> > > > +        )
> > > > +
> > > > +pa_version = meson.project_version()
> > > > +version_split = pa_version.split('.')
> > > > +pa_version_major = version_split[0]
> > > > +pa_version_minor = version_split[1]
> > > > +pa_version_micro = version_split[2]
> > > > +pa_version_major_minor = pa_version_major + '.' + pa_version_minor
> > > > +
> > > > +pa_api_version = 12
> > > > +pa_protocol_version = 31
> > > > +
> > > > +apiversion = '1.0'
> > > > +soversion = 0
> > > > +# maintaining compatibility with the previous libtool versioning
> > > > +# current = minor * 100 + micro
> > > > +libversion = '@0 at .@1 at .0'.format(soversion, pa_version_minor.to_int() * 100 + pa_version_micro.to_int())
> > > 
> > > This gives 0.9901.0 instead of 0.20.2
> > 
> > Yeah, we need to fix it up to do the right thing. Let's fix this in a
> > subsequent patch.
> > 
> > My intention is to not have this be complete, but to have it land in
> > some usable state and incrementally make it better. I expect we'll be
> > supporting autofoo + meson for a while until there is parity between the
> > two (across platforms).
> 
> Do you have a list of what remains to be done? Clearly not everything
> is marked with FIXMEs.

I do not. The goal is feature parity, so anything missing is a FIXME.

> > > > +if cc.has_function('SYS_memfd_create', prefix : '#include <sys/syscall.h>')
> > > > +  cdata.set('HAVE_MEMFD', 1)
> > > > +endif
> > > 
> > > configure has the option to enable or disable this. This meson script
> > > autodetects only. I think the ability to explicitly disable/enable
> > > (and error out if dependencies are not found) is nice to keep when
> > > moving to meson. That is, this should become something like:
> > > 
> > > want_memfd = get_option('memfd')
> > > if want_memfd != 'false'
> > >   has_memfd = cc.has_function('SYS_memfd_create', prefix : '#include
> > > <sys/syscall.h>')
> > >   if has_memfd
> > >     cdata.set('HAVE_MEMFD', 1)
> > >   elif want_memfd == 'true'
> > >     error('Memfd was requested but it was not found')
> > >   endif
> > > endif
> > > 
> > > plus a meson_options.txt:
> > > 
> > > option('memfd', type: 'combo', choices: ['auto', 'true', 'false'],
> > >   description: 'Enable Linux memfd shared memory')
> > > 
> > > This applies to a lot of the checks.
> > 
> > This may be a hard, but in the long run, I actually would like to remove
> > automagic dependencies. This makes builds more consistent, and removes a
> > lot of (imo unnecessary) if/else-ery.
> > 
> > So we would have want_memfd on by default (maybe conditional on OS ==
> > Linux), and then you could disable it at configure time if you don't
> > want it.
> 
> That kind of plan seems likely to cause unnecessary hassle for
> people... I think enabling features automatically based on what's
> available is a good approach.

My rationale for proposing this is largely borrowed from the thinking in
the GNOME project, and is as follows:

  1. Automagic dependencies make builds unpredictable, which makes
  distribution packaging and CI systems more fragile as they become
  dependent on the state of the specific system being built on.

  1.5 I would also argue that this adds the hassle of verifying that
  users who are building the project have a dependency when they are
  doing their own builds.

  2. The pain of knowing what dependencies you need is relatively easily
  solved in documentation for the build -- we can even just provide a
  set of commands to pull in the required dependencies on common
  distributions to make this simpler

  3. Disabling things in the build is quite simple (meson configure
  ...), and can easily be documented.

So while this proposal flies in the face of how we've always done
things, I think the fallout can easily be mitigated with documentation,
and the long-term wins have merit.

Cheers,
Arun