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. > > > > > +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... > 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. -- Tanu https://www.patreon.com/tanuk
