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

[Felipe Sateler]

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
doesn't work.

>
>   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.

-- 

Saludos,
Felipe Sateler