[debhelper-devel] Bug#795253: Bug#795253: Bug#795253: Add support for Meson build system

[Niels Thykier]

Michael Biebl:
> Hi Niels,
> 
> with the release of GNOME 3.24, quite a few GNOME components have
> started to support the Meson build system (in addition to autotools).
> There are even plans for some of them to be Meson-only in the future. So
> this issue will become relevant for the Debian GNOME team.
> 

Hi,

Wed, 12 Aug 2015 16:31:41 +0200 Niels Thykier <niels at thykier.net> wrote:
>>
>> On 2015-08-12 11:55, Jussi Pakkanen wrote:
> 
>>>
>>> Please add support for building packages using the Meson build system. The
>>> exact build steps to take are the following.
>>>
>>> [...]
> 
>>
>> I got a couple of questions:
>>
>>  * How many packages in Debian are (or will in the near future) be
>>    using this build system?
> 
> In GNOME 3.24 I'd say we have around a dozen or more packages supporting
> Meson. This list is expected to grow significantly though.
> 


Ok, seems like a legitimate reason for it for to be included in
debhelper (sooner or later).

>>
>>  * What (build-)dependencies are required for building a package with
>>    Meson/ninja (beyond build-essential)?
> 
> The most important bit is probably that meson is implemented in python3,
> but doesn't have any additional dependencies aside from that.
> ninja(-build) is a rather small C/C++ application.
> 

I could have a concern here with including it due to dependencies.
 * Without the dependency on these,  I am guessing the build system
   would just fail (or silently degrade to a different build system
   which would be even worse).
 * If we depend on them, they and their dependencies de facto become
   (almost) build-essential.  I suspect python would be the main issue
   (although I have not looked at the chains in details)
 * Furthermore, we have to deal with keep things cross-buildable and
   bootstrappable.  Again, these packages may complicate this.


Not saying it cannot be solved, just saying it may need some additional
thought in how we handle this.  Perhaps like splitting debhlper into
two; debhelper providing the default tooling in its full glory and a
debhlper-bootstrap/debhelper-core that has minimum dependencies to ease
bootstrapping etc or whatever make sense (to us once we have had a look
at the actual issues if any)

> 
> 
>>  * Is it possible to reliably auto-detect if an upstream is using Meson
>>    like it is with other build systems such as autoconf+make?
>>    - If not, it can at best be a "manually invoked" build system.
> 
> A meson.build file is probably a good indicator that meson is supported.
> As mentioned earlier, at least some of the GNOME projects will support
> autotools and meson/ninja in parallel for some time. So we'd need a
> mechanism to choose which one to use.
> 

There is an ordering inside debhelper to deal with that, which can be
changed during a compat bump.  Possibly, we need some logic to keep the
meason build lower than the third-party build systems until then as well
(in the off-hand case that meason was /also/ available in packages with
those third party build systems - doubt it, but mentioning it for
completion).

> Niels, do you have any preference how we should approach this:
> Have a separate dh-meson package (built from a separate source package)
> with the option to merge it into debhelper later or should we start
> implementing this directly within debhelper?
> 
> Regards,
> Michael
> 
> [...]

A dh-meson package would avoid most of the initial issues of listed
above and can update in its own pace (without the same regard to compat
bumps, etc).

But either way is fine with me - as long as we have a solution to the
above issues before we upload a debhelper with the meason+ninja build
systems enabled into unstable (feel free to abuse experimental though).

Thanks,
~Niels