Proposal: Recommend meson for glib 2.58.0

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Recommend meson for glib 2.58.0

xclaesse
Hi,

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.

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.

Disclaimer: I'm not a GLib maintainer so this email is only about
opening the discussion. There is no decision made yet.

Opinions?

Regards,
Xavier Claessens.

[1] https://gitlab.gnome.org/GNOME/glib/issues?scope=all&utf8=%E2%9C%93
&state=opened&label_name[]=Meson
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

Christian Hergert
On 06/01/2018 08:10 AM, [hidden email] wrote:
> Disclaimer: I'm not a GLib maintainer so this email is only about
> opening the discussion. There is no decision made yet.
>
> Opinions?

I think the risk area is python3 support on some commercially supported
distributions. Although, that is probably in better shape now than it
was a year ago.

Also not a maintainer, but +1 for the switch.

-- Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

Emmanuele Bassi
With Python 2.x getting EOL in less than 2 years, I suspect that commercial distros will need to provide Python 3 pretty quickly.

Ciao,
 Emmanuele.

On Fri, 1 Jun 2018 at 21:10, Christian Hergert <[hidden email]> wrote:
On 06/01/2018 08:10 AM, [hidden email] wrote:
> Disclaimer: I'm not a GLib maintainer so this email is only about
> opening the discussion. There is no decision made yet.
>
> Opinions?

I think the risk area is python3 support on some commercially supported
distributions. Although, that is probably in better shape now than it
was a year ago.

Also not a maintainer, but +1 for the switch.

-- Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

Ignacio Casal Quinteiro
On the gvsbuild side we are already building with meson for a while and things are ok. I just fear the case where we do not have python 3 on rhel 6 and sles 11...

On Fri, Jun 1, 2018 at 10:51 PM, Emmanuele Bassi <[hidden email]> wrote:
With Python 2.x getting EOL in less than 2 years, I suspect that commercial distros will need to provide Python 3 pretty quickly.

Ciao,
 Emmanuele.

On Fri, 1 Jun 2018 at 21:10, Christian Hergert <[hidden email]> wrote:
On 06/01/2018 08:10 AM, [hidden email] wrote:
> Disclaimer: I'm not a GLib maintainer so this email is only about
> opening the discussion. There is no decision made yet.
>
> Opinions?

I think the risk area is python3 support on some commercially supported
distributions. Although, that is probably in better shape now than it
was a year ago.

Also not a maintainer, but +1 for the switch.

-- Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list




--
Ignacio Casal Quinteiro

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

philip.chimento
Before making the switch please be aware of https://github.com/mesonbuild/meson/issues/3077 and https://github.com/mesonbuild/meson/issues/2121 which make Meson-built libraries mostly broken on macOS, particularly with regard to g-ir-scanner.

Regards,
Philip C

On Sat, Jun 2, 2018 at 12:08 PM Ignacio Casal Quinteiro <[hidden email]> wrote:
On the gvsbuild side we are already building with meson for a while and things are ok. I just fear the case where we do not have python 3 on rhel 6 and sles 11...

On Fri, Jun 1, 2018 at 10:51 PM, Emmanuele Bassi <[hidden email]> wrote:
With Python 2.x getting EOL in less than 2 years, I suspect that commercial distros will need to provide Python 3 pretty quickly.

Ciao,
 Emmanuele.

On Fri, 1 Jun 2018 at 21:10, Christian Hergert <[hidden email]> wrote:
On 06/01/2018 08:10 AM, [hidden email] wrote:
> Disclaimer: I'm not a GLib maintainer so this email is only about
> opening the discussion. There is no decision made yet.
>
> Opinions?

I think the risk area is python3 support on some commercially supported
distributions. Although, that is probably in better shape now than it
was a year ago.

Also not a maintainer, but +1 for the switch.

-- Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list




--
Ignacio Casal Quinteiro
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

Philip Withnall-2
In reply to this post by xclaesse
Hey,

On Fri, 2018-06-01 at 11:10 -0400, [hidden email] 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
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

xclaesse
Le vendredi 08 juin 2018 à 18:59 +0100, Philip Withnall a écrit :
> 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.

Yeah, why not, let's start it slow. What I like with that step is we
can easily roll new tarballs with "make distcheck" if packagers have
any issues.

Btw, when is 2.58.0 due? And how many dev release do we plan in
between?

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

Of course, each step is conditional to the previous going fine.

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

+1

> BTW, why are you recommending 0.46.1? The dependency in our top-level
> meson.build is currently 0.46.0.

Because 0.46.1 is what we have in our CIs, the .1 is only for bug
fixing.

Regards,
Xavier Claessens.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

Tim-Philipp Müller
In reply to this post by Philip Withnall-2
On Fri, 2018-06-08 at 18:59 +0100, Philip Withnall wrote:

Hi,

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

Just to make sure everyone is aware of this, this also means distros
will always need to always build the documentation with gtk-doc, since
"ninja dist" won't include generated html files in the tarball. It just
includes whatever is checked into git (they could be checked into git
of course if that was a deal-breaker for some reason).

Cheers
-Tim
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

Nirbheek Chauhan
In reply to this post by philip.chimento
On Sun, Jun 3, 2018 at 1:13 AM <[hidden email]> wrote:
>
> Before making the switch please be aware of https://github.com/mesonbuild/meson/issues/3077 and https://github.com/mesonbuild/meson/issues/2121 which make Meson-built libraries mostly broken on macOS, particularly with regard to g-ir-scanner.
>

I have a fix for this: https://github.com/mesonbuild/meson/pull/3691

I'll wait till Monday or Tuesday for people to comment and then push
it. It will be in the 0.47 release which is scheduled for 24th June.

Cheers,
Nirbheek
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

philip.chimento
On Sat, Jun 9, 2018 at 8:02 AM Nirbheek Chauhan <[hidden email]> wrote:
On Sun, Jun 3, 2018 at 1:13 AM <[hidden email]> wrote:
>
> Before making the switch please be aware of https://github.com/mesonbuild/meson/issues/3077 and https://github.com/mesonbuild/meson/issues/2121 which make Meson-built libraries mostly broken on macOS, particularly with regard to g-ir-scanner.
>

I have a fix for this: https://github.com/mesonbuild/meson/pull/3691

I'll wait till Monday or Tuesday for people to comment and then push
it. It will be in the 0.47 release which is scheduled for 24th June.

That's fantastic news, thank you Nirbheek!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

Philip Withnall-2
In reply to this post by xclaesse
On Fri, 2018-06-08 at 14:59 -0400, [hidden email] wrote:

> Le vendredi 08 juin 2018 à 18:59 +0100, Philip Withnall a écrit :
> > 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.
>
> Yeah, why not, let's start it slow. What I like with that step is we
> can easily roll new tarballs with "make distcheck" if packagers have
> any issues.
Yup.

> Btw, when is 2.58.0 due? And how many dev release do we plan in
> between?

Due after GUADEC; as many dev releases as we want.

https://wiki.gnome.org/Schedule

Philip
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

xclaesse
In reply to this post by Tim-Philipp Müller
Le vendredi 08 juin 2018 à 20:25 +0100, Tim-Philipp Müller a écrit :
> Just to make sure everyone is aware of this, this also means distros
> will always need to always build the documentation with gtk-doc,
> since
> "ninja dist" won't include generated html files in the tarball. It
> just
> includes whatever is checked into git (they could be checked into git
> of course if that was a deal-breaker for some reason).

Note that the doc is built and uploaded as part of glib's CI for each
tag, so it can be taken from artifacts. I don't know if it gets
published from there, but we could do something. Emmanuele Bassi
probably knows more about this mechanism.

Now that I think about this, the CI could be used to publish
Windows/MacOSX doc as well, I think that's something we never could do
before.

Regards,
Xavier Claessens.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

Emmanuele Bassi
On Fri, 15 Jun 2018 at 16:34, <[hidden email]> wrote:
Le vendredi 08 juin 2018 à 20:25 +0100, Tim-Philipp Müller a écrit :
> Just to make sure everyone is aware of this, this also means distros
> will always need to always build the documentation with gtk-doc,
> since
> "ninja dist" won't include generated html files in the tarball. It
> just
> includes whatever is checked into git (they could be checked into git
> of course if that was a deal-breaker for some reason).

Note that the doc is built and uploaded as part of glib's CI for each
tag, so it can be taken from artifacts. I don't know if it gets
published from there, but we could do something. Emmanuele Bassi
probably knows more about this mechanism.

It doesn't get published, only built and stored as artefacts – though it's mostly a demonstration of what could be done.

The main issue with using GitLab pages is that publishing wipes out the deployment every time, so we cannot have things like "publish the API reference for master under unstable/ and the API reference for for each branch under branchname/ and then publish the test suite coverage under coverage/".

The only way to achieve this would be to build the API reference then push it to some other repository, and have a CI hook that deploys everything. This would allow building different versions of the API reference, and additionally have things like coverage (per branch) and a simple website. I've started looking into this, but it's kind of complicated, as it requires creating a new `glib-docs` user and repo; generate SSH keys for it; and then have the CI infrastructure store the SSH keys as secrets and use them during the CI build.

Alternatively, we'd need a place accessible from the CI infra to copy our files into, that would get published automatically on our web servers.

Ideally, this would also serve as the replacement for developer.gnome.org.

Ciao,
 Emmanuele.

--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Recommend meson for glib 2.58.0

xclaesse
Le vendredi 15 juin 2018 à 17:41 +0100, Emmanuele Bassi a écrit :
> Note that the doc is built and uploaded as part of glib's CI for
> > each
> > tag, so it can be taken from artifacts. I don't know if it gets
> > published from there, but we could do something. Emmanuele Bassi
> > probably knows more about this mechanism.

Oh... but it's broken: https://gitlab.gnome.org/GNOME/glib/-/jobs/35826

the CI is missing "ninja gobject-doc" and "ninja gio-doc" commands, but
they fail: https://github.com/mesonbuild/meson/issues/3745
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list