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


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:


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


Attachment: signature.asc
Description: This is a digitally signed message part

gtk-devel-list mailing list

Reply via email to