[pulseaudio-discuss] [PATCH] build-sys: First pass at a meson-ified build system
fsateler at debian.org
Tue Dec 12 13:48:59 UTC 2017
On Tue, Dec 12, 2017 at 1:17 AM, Arun Raghavan <arun at arunraghavan.net> 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:
>> > 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.
I support this as downstream packager. I want my build to fail if a
dependency is missing instead of silently turning off a feature.
> 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.
A slightly different way to say this is that things fails fast when a
dependency is missing. So we get a rapid build failure instead of
having the build complete and then the user wonder why bluetooth
> 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.
I would tend to agree.
More information about the pulseaudio-discuss