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

[Michael Biebl]

Hi

Am 24.03.2017 um 06:28 schrieb Niels Thykier:
> Michael Biebl:
> Wed, 12 Aug 2015 16:31:41 +0200 Niels Thykier <niels at thykier.net> wrote:
>>>
>>> On 2015-08-12 11:55, Jussi Pakkanen wrote:
>>
>>>
>>>  * 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)


So, I thought about this and I think it's a non-issue.
debhelper already ships build classes for e.g. cmake and qmake but does
not actually declare a dependency on those packages. It expect the
packages using cmake/qmake to add that Build-Depends themselves. The
same would be true for meson. Packages using that build system would add
meson to Build-Depends.

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

Thanks for the hint. I was already pointed at this on IRC.
The biebl/meson branch adds meson to the list as last option. Which
means a package shipping both autotools and meson support would get
autotools by default, which is ok I guess.

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

I started working on this a bit, see the aforementioned biebl/meson
branch in debhelper.git.

Thought/review welcome, especially with regards to cross-building which
I left out completely.

Jussi, maybe you have some experience with that.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20170324/707fd723/attachment.sig>