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

Arun Raghavan arun at arunraghavan.net
Wed Dec 13 12:31:13 UTC 2017 


On Wed, 13 Dec 2017, at 12:10 PM, Tanu Kaskinen wrote:
> On Tue, 2017-12-12 at 09:47 +0530, Arun Raghavan wrote:
> > 
> > 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.
> 
> How do you know when you have reached feature parity? I see two
> possible approaches: someone does careful review of everything that our
> old build system does and makes a todo list, or we carry both build
> systems for many years until we can be sure that all missing things
> have been catched via bug reports. I would prefer the first approach,
> but I'm not volunteering to do the review.

I don't think we have a choice but to carry both systems for a long time
-- I can't foresee meson rendering autofoo obsolete on every platform we
support for at least another year, likely longer.

This is why I'm okay with postponing making a thorough comparison of
features implemented until some future point when we're much further
along and able to consider meson the "default" build system in some
sense. 
 
> > > > > > +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.
> 
> This is certainly true. Automatic dependencies at least used to cause
> trouble in OpenEmbedded. (I'm not sure if that's the case any more,
> because packages are built in more isolated environments nowadays.)
> 
> >   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
> 
> I'm a bit worried that the "we can" is not very likely going to
> translate into "we will", since it's not a requirement for making
> things work...

FWIW, I have some documentation on the GStreamer side that we can adapt
once we're ready to recommend the meson tools as the way to go.
http://arunraghavan.net/2014/07/quick-start-guide-to-gst-uninstalled-1-x/

> >   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.
> 
> Ok, I believe this is a beneficial change after all.

Cheers,
Arun

More information about the pulseaudio-discuss mailing list