Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
Michael Biebl: > [...] > > I've addressed those issues, thanks for your help, Niels. > > Aside from cross-build support and the autoreconf issue, I consider the > current state in biebl/meson usable enough to be merged. > > I would squash the individual commits and write a proper commit log if > you are happy with the code. > > Regards, > Michael > Hi, I have reviewed it and it looks fine, please do a rebase+squash and then merge. :) Thanks, ~Niels
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
Michael Biebl: > Am 25.03.2017 um 09:34 schrieb Niels Thykier: >> [...] >> > > I've addressed those issues, thanks for your help, Niels. > Thanks for doing the work. :) > Aside from cross-build support and the autoreconf issue, I consider the > current state in biebl/meson usable enough to be merged. > > I would squash the individual commits and write a proper commit log if > you are happy with the code. > > Regards, > Michael > Thanks. I will have a look at it soon, but I have a bit on my table this week. If you have not heard from me on this by Tuesday, please ping me about it. Thanks, ~Niels
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
Am 25.03.2017 um 09:34 schrieb Niels Thykier: > Michael Biebl: >> Am 24.03.2017 um 08:31 schrieb Niels Thykier: >>> >From what little I know about meson + ninja, looks fine. The only >>> comment I have is that the ninja file speaks a lot about Makefiles >>> without the code ever touching one. :) Guess it is copy-waste >>> left-overs from make.pm? >> >> Yeah, thanks for spotting. I fixed that. >> >> I've also added a couple of notes/TODOs to the code >> >> a/ Add support for DEB_BUILD_OPTIONS="parallel=N"? >> By default ninja runs N jobs in parallel, where N is derived >> from the number of CPUs. > > Should be trivial to do with : > > unshift @_, "-j" . ( >$this->get_parallel() > 0 ? >$this->get_parallel() : "" > ); > > >> [...] >> >> b/ Add support for DH_QUIET, i.e. don't run with ninja -v in quiet mode. >> >> c/ The install target mangles $ENV to set DESTDIR, which is a bit meh. >> Should we save and restore $ENV? >> > > Nope, don't bother. Most debhelper scripts don't do this either (see > e.g. perl_maker.pm) > I've addressed those issues, thanks for your help, Niels. Aside from cross-build support and the autoreconf issue, I consider the current state in biebl/meson usable enough to be merged. I would squash the individual commits and write a proper commit log if you are happy with the code. Regards, Michael -- 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
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
On Mon, Mar 27, 2017 at 8:07 PM, Michael Biebl wrote: > Ok, os ninja does not automatically translate -j1 to MESON_TESTTHREADS=1 No. > To understand this properly: Say I have 4 cores, does that mean that by > default I have 4 ninja processes which run mesontest, which in turn runs > 4 threads, so I have 4x4=16 tests that are run in parallel? No. There is never more than on test runner going at once. If you have built your project then running 'ninja test' is the same as 'ninja -j 4 test' and even 'ninja -j 1024 test'. Test is only ever run once and when it is running, nothing else is running at the same time.
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
Am 27.03.2017 um 18:33 schrieb Jussi Pakkanen: > On Mon, Mar 27, 2017 at 7:24 PM, Michael Biebl wrote: > >> So, when running "ninja test -j1" will the -j1 be ignored? > > Well yes and no. It tells Ninja to use only one parallel process. > Which it uses to spawn the test runner which then uses > MESON_TESTTHREADS amount of parallel processes. Ok, os ninja does not automatically translate -j1 to MESON_TESTTHREADS=1 To understand this properly: Say I have 4 cores, does that mean that by default I have 4 ninja processes which run mesontest, which in turn runs 4 threads, so I have 4x4=16 tests that are run in parallel? -- 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
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
On Mon, Mar 27, 2017 at 7:24 PM, Michael Biebl wrote: > So, when running "ninja test -j1" will the -j1 be ignored? Well yes and no. It tells Ninja to use only one parallel process. Which it uses to spawn the test runner which then uses MESON_TESTTHREADS amount of parallel processes.
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
Hi Jussi Am 24.03.2017 um 17:46 schrieb Jussi Pakkanen: > On Fri, Mar 24, 2017 at 6:05 PM, Michael Biebl wrote: > >> a/ Add support for DEB_BUILD_OPTIONS="parallel=N"? >> By default ninja runs N jobs in parallel, where N is derived >> from the number of CPUs. >> Should this be only done for the build step or install and test as well? >> In the latter case, the code to run buildcmd should be factored out. >> Or do we just keep ninja's default behaviour and don't bother setting -j >> manually. > > 'ninja install' only invokes Meson's internal installer program. It > always runs single threaded. Ah, good to know. > 'ninja test' invokes Meson's test runner. By default it uses N > processes to run tests where N is the number of processors. This can > be overridden with the environment variable MESON_TESTTHREADS. So, when running "ninja test -j1" will the -j1 be ignored? -- 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
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
Michael Biebl: > Am 24.03.2017 um 08:31 schrieb Niels Thykier: >> >From what little I know about meson + ninja, looks fine. The only >> comment I have is that the ninja file speaks a lot about Makefiles >> without the code ever touching one. :) Guess it is copy-waste >> left-overs from make.pm? > > Yeah, thanks for spotting. I fixed that. > > I've also added a couple of notes/TODOs to the code > > a/ Add support for DEB_BUILD_OPTIONS="parallel=N"? > By default ninja runs N jobs in parallel, where N is derived > from the number of CPUs. Should be trivial to do with : unshift @_, "-j" . ( $this->get_parallel() > 0 ? $this->get_parallel() : "" ); > [...] > > b/ Add support for DH_QUIET, i.e. don't run with ninja -v in quiet mode. > > c/ The install target mangles $ENV to set DESTDIR, which is a bit meh. > Should we save and restore $ENV? > Nope, don't bother. Most debhelper scripts don't do this either (see e.g. perl_maker.pm) > Input welcome. > >> Re: cross-build, Helmut is usually my goto person for that. Admittedly, >> he usually contacts me when he discovers an issue. Anyway, per above, I >> have BCC'ed him, so he at least knows about this work. :) > > In theory, meson does support cross building > https://github.com/mesonbuild/meson/wiki/Cross-compilation > > I personally do not have experience with it though. So I would need help > with implementing that or leave that to someone else. I wouldn't make > this a blocker though, for merging meson/ninja support. > > Regards, > Michael > Indeed, not a blocker. Thanks, ~Niels
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
On Fri, Mar 24, 2017 at 6:05 PM, Michael Biebl wrote: > a/ Add support for DEB_BUILD_OPTIONS="parallel=N"? > By default ninja runs N jobs in parallel, where N is derived > from the number of CPUs. > Should this be only done for the build step or install and test as well? > In the latter case, the code to run buildcmd should be factored out. > Or do we just keep ninja's default behaviour and don't bother setting -j > manually. 'ninja install' only invokes Meson's internal installer program. It always runs single threaded. 'ninja test' invokes Meson's test runner. By default it uses N processes to run tests where N is the number of processors. This can be overridden with the environment variable MESON_TESTTHREADS. > In theory, meson does support cross building > https://github.com/mesonbuild/meson/wiki/Cross-compilation > > I personally do not have experience with it though. So I would need help > with implementing that or leave that to someone else. I wouldn't make > this a blocker though, for merging meson/ninja support. For cross compilation Meson requires a "cross file" describing the toolchain and environment to use. These should probably be provided by the dh_meson package (you need one per target platform). After that cross compilation is just a matter of adding --cross-file=/path/to/toolchain/file. I'm not sure how Debian's cross environment works in detail, but Meson expects to also find the native compiler. If /usr/bin/cc (et al) points to the native compiler then everything is fine, otherwise the build runner needs to set CC, CXX et al.
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
Am 24.03.2017 um 08:31 schrieb Niels Thykier: >>From what little I know about meson + ninja, looks fine. The only > comment I have is that the ninja file speaks a lot about Makefiles > without the code ever touching one. :) Guess it is copy-waste > left-overs from make.pm? Yeah, thanks for spotting. I fixed that. I've also added a couple of notes/TODOs to the code a/ Add support for DEB_BUILD_OPTIONS="parallel=N"? By default ninja runs N jobs in parallel, where N is derived from the number of CPUs. Should this be only done for the build step or install and test as well? In the latter case, the code to run buildcmd should be factored out. Or do we just keep ninja's default behaviour and don't bother setting -j manually. b/ Add support for DH_QUIET, i.e. don't run with ninja -v in quiet mode. c/ The install target mangles $ENV to set DESTDIR, which is a bit meh. Should we save and restore $ENV? Input welcome. > Re: cross-build, Helmut is usually my goto person for that. Admittedly, > he usually contacts me when he discovers an issue. Anyway, per above, I > have BCC'ed him, so he at least knows about this work. :) In theory, meson does support cross building https://github.com/mesonbuild/meson/wiki/Cross-compilation I personally do not have experience with it though. So I would need help with implementing that or leave that to someone else. I wouldn't make this a blocker though, for merging meson/ninja support. Regards, Michael -- 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
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
Michael Biebl: > Hi > Hi, BCCed Helmut Grohne: @Helmut, we are talking about adding a new build system to debhelper (meson + ninja). I wanted you to be aware of it in case you had some early remarks on doing cross-building with it (see the last paragraphs). :) > Am 24.03.2017 um 06:28 schrieb Niels Thykier: >> [...] > > > 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. > So it does. Sorry for sleeping in class. :) Indeed, as long as we can do the detection without any special Build-Depends, we should be good (which seems to be the case here). >> [...] >> >> 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. > Thanks. We can always chance that order in a later compat. :) >> 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. > > [...] >From what little I know about meson + ninja, looks fine. The only comment I have is that the ninja file speaks a lot about Makefiles without the code ever touching one. :) Guess it is copy-waste left-overs from make.pm? Re: cross-build, Helmut is usually my goto person for that. Admittedly, he usually contacts me when he discovers an issue. Anyway, per above, I have BCC'ed him, so he at least knows about this work. :) Thanks, ~Niels
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
For anyone interested: I started working on meson/ninja support at https://anonscm.debian.org/cgit/debhelper/debhelper.git/log/?h=biebl/meson It's based on the autoconf/makefile class. I tested it with a a few packages like gnome-twitch and it more or less seems to do the right thing. I don't consider it ready yet though. Feedback and testing welcome. Atm it uses ninja's default setup for -j, which is derived from the number of cores. -- 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
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
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. On Wed, 12 Aug 2015 16:31:41 +0200 Niels Thykier 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. > > * 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. > * 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. 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 -- 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
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
On Wed, Aug 12, 2015 at 4:31 PM, Niels Thykier wrote: I got a couple of questions: > > * How many packages in Debian are (or will in the near future) be >using this build system? > As far as I can tell, at the moment the number is zero. There have been talks with upstream maintainers of some projects but AFAIK no project currently uses only Meson to build. > * What (build-)dependencies are required for building a package with >Meson/ninja (beyond build-essential)? > For building there are none. Only Meson, which has a dependency on Ninja, so it should work automatically for all packages that declare a build-dep on Meson. > * 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. > The way to detect this is to look at the top level extracted source dir. If there is a meson.build file then you should build with Meson. Thanks,
Bug#795253: [debhelper-devel] Bug#795253: Add support for Meson build system
Control: tags -1 moreinfo On 2015-08-12 11:55, Jussi Pakkanen wrote: > Package: debhelper > Version: 9.20150811 > Severity: wishlist > > Please add support for building packages using the Meson build system. The > exact build steps to take are the following. > > [...] > > Thanks, > > [...] Hi, Thanks for the suggestion and the basic information about Meson. I got a couple of questions: * How many packages in Debian are (or will in the near future) be using this build system? * What (build-)dependencies are required for building a package with Meson/ninja (beyond build-essential)? * 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. Thanks, ~Niels
