Hey, On Fri, 2018-06-01 at 11:10 -0400, xclaesse 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
Attachment:
signature.asc
Description: This is a digitally signed message part