Hey, On Fri, 2018-06-01 at 11:10 -0400, xclae...@gmail.com wrote: > Things are looking pretty well with meson in GLib master. We have CI > working for pretty much all interesting platforms (more to come) and > there are only a few remaining issues with "Meson" tag in gitlab[1]. > > I think the longer we keep 2 build systems, the more time we waste on > useless tasks. So I would like to discuss a roadmap that would lead > to > dropping autotools.
Yes, it would be good to clarify the roadmap. A roadmap was planned at the GTK+ hackfest at FOSDEM earlier this year, and I blogged about it, but it looks like my blog had dropped off planet.gnome.org at the time, so I doubt anyone saw the post. ☹ https://tecnocode.co.uk/2018/02/06/gtk-hackfest-and-fosdem-outcomes/ tl;dr: The plan from FOSDEM was to support autotools and Meson in parallel for 2.58 (with feature parity between the two), then keep both systems in parallel for a ‘release or two’, before dropping autotools as soon as we can be satisfied there are no regressions for our features or supported platforms. As a reminder, here’s the set of supported platforms for GLib: https://wiki.gnome.org/Projects/GLib/SupportedPlatforms > My proposal would be: > 1) Starting from 2.57.2 (next dev release), create release tarballs > using "ninja dist" and recommend disto to build with Meson 0.46.1. > This > would mean that './configure' in a release tarball won't work, people > still wanting to use autotools will have to update their scripts to > use > "./autogen.sh" instead and adjust their build deps. IMHO, forcing a > small change is a good incentive to have most of our users switch to > meson. This would give us good feedback while still keeping the door > open to rollback if any blocker bug appears. > 2) Starting from 2.59.1 (next dev cycle), drop autotools completely > from our git repository. How about: 1) Starting from 2.57.2, create release tarballs with `ninja dist`, but recommend that distributions still build with autotools (unless they want to dogfood with Meson early). 2) From 2.57.3, switch to recommending that distributions build with Meson. 3) Starting from 2.59.0 (the actual start of next dev cycle), drop autotools completely; assuming that steps 1 and 2 have gone OK. I want to make sure that distributions only start building GLib using Meson for their unstable/development releases, rather than for stable releases. There have only recently been bugs about code which was compiled with autotools not being built with Meson (the FAM file monitor comes to mind), which doesn’t give me enough confidence to jump to recommending building with Meson right yet. Note that on some platforms, we may drop support for autotools early. Notably the maintainers of the GLib builds on Windows have already fully switched to Meson, and there is a merge request open about making configure error out on Windows. I could imagine the same happening for other platforms where we’re in direct contact with the small set of packagers for those platforms (for example, MacPorts and the *BSDs). BTW, why are you recommending 0.46.1? The dependency in our top-level meson.build is currently 0.46.0. Philip
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
