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
