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
