Hi Am 24.03.2017 um 06:28 schrieb Niels Thykier: > Michael Biebl: > Wed, 12 Aug 2015 16:31:41 +0200 Niels Thykier <ni...@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?
signature.asc
Description: OpenPGP digital signature
