Re: Proposal: Recommend meson for glib 2.58.0
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 gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
On Fri, 15 Jun 2018 at 16:34, 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. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
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 gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
On Fri, 2018-06-08 at 14:59 -0400, xclae...@gmail.com 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 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
Re: Proposal: Recommend meson for glib 2.58.0
On Sat, Jun 9, 2018 at 8:02 AM Nirbheek Chauhan wrote: > On Sun, Jun 3, 2018 at 1:13 AM 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 gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
On Sun, Jun 3, 2018 at 1:13 AM 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 gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
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 gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
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 gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
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
Re: Proposal: Recommend meson for glib 2.58.0
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 < nacho.r...@gmail.com> 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 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 >> wrote: >> >>> On 06/01/2018 08:10 AM, xclae...@gmail.com 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 >>> gtk-devel-list@gnome.org >>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list >>> >> -- >> https://www.bassi.io >> [@] ebassi [@gmail.com] >> >> ___ >> gtk-devel-list mailing list >> gtk-devel-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-devel-list >> >> > > > -- > Ignacio Casal Quinteiro > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
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 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 > wrote: > >> On 06/01/2018 08:10 AM, xclae...@gmail.com 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 >> gtk-devel-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-devel-list >> > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
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 wrote: > On 06/01/2018 08:10 AM, xclae...@gmail.com 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 > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
On 06/01/2018 08:10 AM, xclae...@gmail.com 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 gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Proposal: Recommend meson for glib 2.58.0
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=%E2%9C%93 =opened_name[]=Meson ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
