Re: For projects switching to Meson *only*
On Sat, 2017-04-29 at 12:06 -0500, mcatanz...@gnome.org wrote: > On Sat, Apr 29, 2017 at 7:45 AM, Bastien Nocera> wrote: > > Are you saying you reverted jhbuild module changes, without > > notifying > > the committer, because there's a problem with the grilo/grilo- > > plugins > > handling, > > I did notify the committer (Javier). > > > but you didn't file a bug against those modules? > > Due to the large number of build failures we have to deal with when > releasing, I normally only file bugs on release day if I can't get > the > modules to build at all. I filed: https://bugzilla.gnome.org/show_bug.cgi?id=782055 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Fri, Apr 28, 2017 at 10:34:03AM +0100, Richard Hughes wrote: > On 28 April 2017 at 01:00, Peter Huttererwrote: > > I will, but I'll keep the two parallel for at least a release or two. > > I tried doing this in my projects last cycle and was a bit of a > disaster. Pretty much any committer that added files or changed how > the project was built, broke one of the two systems. Asking people to > test two quite different build systems before sending patches is > raising the bar a little too high and adding confusion. IMHO, etc. Yeah, I can see that. 'fortunately', libinput has a continuos contributor count of approximately 1, so I guess having all contributors test two build systems won't be the biggest issue ;) Cheers, Peter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Sat, Apr 29, 2017 at 7:45 AM, Bastien Nocerawrote: Are you saying you reverted jhbuild module changes, without notifying the committer, because there's a problem with the grilo/grilo-plugins handling, I did notify the committer (Javier). but you didn't file a bug against those modules? Due to the large number of build failures we have to deal with when releasing, I normally only file bugs on release day if I can't get the modules to build at all. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Fri, 2017-04-28 at 10:19 -0500, mcatanz...@gnome.org wrote: > On Fri, Apr 28, 2017 at 4:40 AM, Bastien Nocera> wrote: > > On Fri, 2017-04-28 at 00:37 -0500, mcatanz...@gnome.org wrote: > > > On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer > > > wrote: > > > > I will, but I'll keep the two parallel for at least a release > > > or > > > > two. > > > > If you > > > > need me to add anything specific to keep continuous happy for > > > the > > > > time > > > > being, let me know. > > > > > > > > Cheers, > > > >Peter > > > > > > Here's a request for maintainers who are supporting both meson > > > and > > > Autotools: please consider adding the meson build files to your > > > release > > > tarballs (add them to EXTRA_DIST) if you want people to actually > > > use > > > the meson build system. You don't have to, but it'd be nice. > > > > > > For people helping maintain the jhbuild modulesets, please do > > > not > > > switch modules to use meson until the meson build files have > > > appeared > > > in a release tarball, or you're confident they will appear in > > > the > > > next > > > tarball. (Unless Autotools support has already been dropped, in > > > which > > > case maintainers, please follow the GNOME release cycle in > > > making > > > your > > > next release!) This will reduce the amount of manual hacking > > > required > > > to produce release modulesets that actually build. I've > > > temporarily > > > switched GStreamer and Grilo back to using Autotools for this > > > reason. > > > > What was the problem with Grilo's meson support? > > > > We have a bug opened for a regression with the 0.4.0 version, but > > the > > meson build works as expected in jhbuild. > > > > Cheers > > Problem with grilo is there are no meson build files in the latest > release tarballs, and the modulesets need to work when converted to > tarballs for our release process. Are you saying you reverted jhbuild module changes, without notifying the committer, because there's a problem with the grilo/grilo-plugins handling, but you didn't file a bug against those modules? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Fri, Apr 28, 2017 at 4:40 AM, Bastien Nocerawrote: On Fri, 2017-04-28 at 00:37 -0500, mcatanz...@gnome.org wrote: On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer wrote: > I will, but I'll keep the two parallel for at least a release or > two. > If you > need me to add anything specific to keep continuous happy for the > time > being, let me know. > > Cheers, >Peter Here's a request for maintainers who are supporting both meson and Autotools: please consider adding the meson build files to your release tarballs (add them to EXTRA_DIST) if you want people to actually use the meson build system. You don't have to, but it'd be nice. For people helping maintain the jhbuild modulesets, please do not switch modules to use meson until the meson build files have appeared in a release tarball, or you're confident they will appear in the next tarball. (Unless Autotools support has already been dropped, in which case maintainers, please follow the GNOME release cycle in making your next release!) This will reduce the amount of manual hacking required to produce release modulesets that actually build. I've temporarily switched GStreamer and Grilo back to using Autotools for this reason. What was the problem with Grilo's meson support? We have a bug opened for a regression with the 0.4.0 version, but the meson build works as expected in jhbuild. Cheers Problem with grilo is there are no meson build files in the latest release tarballs, and the modulesets need to work when converted to tarballs for our release process. By the way, I'm told the latest GStreamer tarballs are unproblematic, so I switched it back to Meson. Turns out I just forgot to remove our GStreamer version limit that we had used for 3.24. We don't have any way to automatically handle unstable versions of dependencies that aren't using the GNOME release cycle but which we still want to build from git usually. :( Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Fri, 2017-04-28 at 00:37 -0500, mcatanz...@gnome.org wrote: > On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer >wrote: > > I will, but I'll keep the two parallel for at least a release or > > two. > > If you > > need me to add anything specific to keep continuous happy for the > > time > > being, let me know. > > > > Cheers, > > Peter > > Here's a request for maintainers who are supporting both meson and > Autotools: please consider adding the meson build files to your > release > tarballs (add them to EXTRA_DIST) if you want people to actually use > the meson build system. You don't have to, but it'd be nice. > > For people helping maintain the jhbuild modulesets, please do not > switch modules to use meson until the meson build files have > appeared > in a release tarball, or you're confident they will appear in the > next > tarball. (Unless Autotools support has already been dropped, in > which > case maintainers, please follow the GNOME release cycle in making > your > next release!) This will reduce the amount of manual hacking > required > to produce release modulesets that actually build. I've temporarily > switched GStreamer and Grilo back to using Autotools for this reason. What was the problem with Grilo's meson support? We have a bug opened for a regression with the 0.4.0 version, but the meson build works as expected in jhbuild. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On 28 April 2017 at 01:00, Peter Huttererwrote: > I will, but I'll keep the two parallel for at least a release or two. I tried doing this in my projects last cycle and was a bit of a disaster. Pretty much any committer that added files or changed how the project was built, broke one of the two systems. Asking people to test two quite different build systems before sending patches is raising the bar a little too high and adding confusion. IMHO, etc. Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Thu, Apr 27, 2017 at 7:00 PM, Peter Huttererwrote: I will, but I'll keep the two parallel for at least a release or two. If you need me to add anything specific to keep continuous happy for the time being, let me know. Cheers, Peter Here's a request for maintainers who are supporting both meson and Autotools: please consider adding the meson build files to your release tarballs (add them to EXTRA_DIST) if you want people to actually use the meson build system. You don't have to, but it'd be nice. For people helping maintain the jhbuild modulesets, please do not switch modules to use meson until the meson build files have appeared in a release tarball, or you're confident they will appear in the next tarball. (Unless Autotools support has already been dropped, in which case maintainers, please follow the GNOME release cycle in making your next release!) This will reduce the amount of manual hacking required to produce release modulesets that actually build. I've temporarily switched GStreamer and Grilo back to using Autotools for this reason. Thanks, Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Thu, Apr 27, 2017 at 03:24:24PM +0100, Emmanuele Bassi wrote: > Replying to both Michael's and Iain at the same time, to reduce the > amount of email. > > On 27 April 2017 at 15:04, Michael Catanzarowrote: > > On Thu, Apr 27, 2017 at 4:11 AM, Iain Lane wrote: > >> > >> As it happens I interacted with this script (in gnome-software) > >> yesterday. I hadn't got a new enough jhbuild - the one I had was trying > >> to call ./configure instead of meson directly. > >> > >> The script AFAICS ignores unknown arguments. In particular, I was > >> interested in passing some --enable/--disable flags to select features > >> but I didn't find out how to do that short of explicitly extending it > >> with those particular options. If you expect distributors to be using > >> this, or if this is interesting for users of the build API, is having > >> some support for ./configure <-> meson_options integration a reasonable > >> request? > > Each module has its own set of options with their own name and > semantics; the build-api only defines a specific subset, so if you > want to have a `configure` script to paper over the Meson switch, you > also get to add the options you want to port over. > > Mostly because if I end up patching this script into Continuous, then > I get to be the one who decides which options get ported over and > which one don't; maintainers of a project are usually best suited at > that. > > For instance, the libinput maintainer has started dropping all > auto-detection checks and now the build relies on specifying all > options; a worthy goal, and I'd actually hope more modules followed > suit. If he also switched to Meson-only, I'd have to write a patch for > Continuous that manually ported over the build options as a > compatibility layer; I would do this only for the options Continuous > supports, though, and it would take me slightly more time than just > copying the file over. I will, but I'll keep the two parallel for at least a release or two. If you need me to add anything specific to keep continuous happy for the time being, let me know. Cheers, Peter > > >> Otherwise, and this is what happens now that I upgraded jhbuild, using > >> meson directly works fine. But if a goal of this is to smooth the > >> transition path and avoid a requirement for tooling to be updated, maybe > >> it would be useful. > > Of course. > > > This compatibility issue seems like a very good argument for shipping the > > "compatibility" script in Continuous patches rather than application > > repositories. > > As I said, this takes me (in the absolute simplest case) about 90 > seconds of my life, so I don't mind doing a patch. > > I'd be happier, though, if maintainers that are planning to drop > autotools also dropped me a line so that I don't wake up to a string > of failed builds and then have to figure out whether or not this was a > planned break, or just general CI failure. *Especially* if the > maintainer also fixes the jhbuild moduleset. > > So, I guess the real question is: communicate these changes > beforehand, instead of pushing to master and then going home without > looking at the explosion? > > Ciao, > Emmanuele. > > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Thu, Apr 27, 2017 at 9:24 AM, Emmanuele Bassiwrote: I'd be happier, though, if maintainers that are planning to drop autotools also dropped me a line so that I don't wake up to a string of failed builds and then have to figure out whether or not this was a planned break, or just general CI failure. *Especially* if the maintainer also fixes the jhbuild moduleset. So, I guess the real question is: communicate these changes beforehand, instead of pushing to master and then going home without looking at the explosion? Yes, and my apologies for failing to do this yesterday when I switched over Epiphany. I even left JHBuild broken. Maintainers, please don't do that. :) Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
Replying to both Michael's and Iain at the same time, to reduce the amount of email. On 27 April 2017 at 15:04, Michael Catanzarowrote: > On Thu, Apr 27, 2017 at 4:11 AM, Iain Lane wrote: >> >> As it happens I interacted with this script (in gnome-software) >> yesterday. I hadn't got a new enough jhbuild - the one I had was trying >> to call ./configure instead of meson directly. >> >> The script AFAICS ignores unknown arguments. In particular, I was >> interested in passing some --enable/--disable flags to select features >> but I didn't find out how to do that short of explicitly extending it >> with those particular options. If you expect distributors to be using >> this, or if this is interesting for users of the build API, is having >> some support for ./configure <-> meson_options integration a reasonable >> request? Each module has its own set of options with their own name and semantics; the build-api only defines a specific subset, so if you want to have a `configure` script to paper over the Meson switch, you also get to add the options you want to port over. Mostly because if I end up patching this script into Continuous, then I get to be the one who decides which options get ported over and which one don't; maintainers of a project are usually best suited at that. For instance, the libinput maintainer has started dropping all auto-detection checks and now the build relies on specifying all options; a worthy goal, and I'd actually hope more modules followed suit. If he also switched to Meson-only, I'd have to write a patch for Continuous that manually ported over the build options as a compatibility layer; I would do this only for the options Continuous supports, though, and it would take me slightly more time than just copying the file over. >> Otherwise, and this is what happens now that I upgraded jhbuild, using >> meson directly works fine. But if a goal of this is to smooth the >> transition path and avoid a requirement for tooling to be updated, maybe >> it would be useful. Of course. > This compatibility issue seems like a very good argument for shipping the > "compatibility" script in Continuous patches rather than application > repositories. As I said, this takes me (in the absolute simplest case) about 90 seconds of my life, so I don't mind doing a patch. I'd be happier, though, if maintainers that are planning to drop autotools also dropped me a line so that I don't wake up to a string of failed builds and then have to figure out whether or not this was a planned break, or just general CI failure. *Especially* if the maintainer also fixes the jhbuild moduleset. So, I guess the real question is: communicate these changes beforehand, instead of pushing to master and then going home without looking at the explosion? Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
On Thu, Apr 27, 2017 at 4:11 AM, Iain Lanewrote: As it happens I interacted with this script (in gnome-software) yesterday. I hadn't got a new enough jhbuild - the one I had was trying to call ./configure instead of meson directly. The script AFAICS ignores unknown arguments. In particular, I was interested in passing some --enable/--disable flags to select features but I didn't find out how to do that short of explicitly extending it with those particular options. If you expect distributors to be using this, or if this is interesting for users of the build API, is having some support for ./configure <-> meson_options integration a reasonable request? Otherwise, and this is what happens now that I upgraded jhbuild, using meson directly works fine. But if a goal of this is to smooth the transition path and avoid a requirement for tooling to be updated, maybe it would be useful. This compatibility issue seems like a very good argument for shipping the "compatibility" script in Continuous patches rather than application repositories. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
Hiya, Apologies for any ignorance about the scope and intent of the build API. On Thu, Apr 27, 2017 at 09:45:04AM +0100, Emmanuele Bassi wrote: > Hi everyone; > A simple script is available here[2], and it has nice properties, like > being able to work with a simple: > > ./configure > make > sudo make install > > which makes distributors and integrators happy. > […] > [2]: https://github.com/ebassi/graphene/blob/master/configure As it happens I interacted with this script (in gnome-software) yesterday. I hadn't got a new enough jhbuild - the one I had was trying to call ./configure instead of meson directly. The script AFAICS ignores unknown arguments. In particular, I was interested in passing some --enable/--disable flags to select features but I didn't find out how to do that short of explicitly extending it with those particular options. If you expect distributors to be using this, or if this is interesting for users of the build API, is having some support for ./configure <-> meson_options integration a reasonable request? Otherwise, and this is what happens now that I upgraded jhbuild, using meson directly works fine. But if a goal of this is to smooth the transition path and avoid a requirement for tooling to be updated, maybe it would be useful. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
The issue is not writing a simple patch: it takes me about 90 seconds of my life to copy the file, create a commit, format-patch it, and add the patch to gnome-continuous. The whole point would be to avoid adding a patch to Continuous. Additionally, conforming to the build-api is a nice transitional tool for distributors that are still trying to catch up to Meson. Ciao, Emmanuele. On 27 April 2017 at 09:48, Carlos Soriano <csori...@protonmail.com> wrote: > Hello Emmanuele, > > Would be fine if the maintainer does the patch for continuous instead of > doing the build-API? > > Carlos Soriano > > Original Message ---- > Subject: For projects switching to Meson *only* > Local Time: 27 April 2017 10:45 AM > UTC Time: 27 April 2017 08:45 > From: eba...@gmail.com > To: Desktop Development List <desktop-devel-list@gnome.org> > > Hi everyone; > > since maintainers have started switching to Meson for the development > cycle (awesome!) I'd like to ask for a favour: if you're dropping > autotools entirely, could you please add a `configure` wrapper script > that conforms to the build-api[1] that GNOME Continuous uses? > > A simple script is available here[2], and it has nice properties, like > being able to work with a simple: > > ./configure > make > sudo make install > > which makes distributors and integrators happy. > > Before you ask: yes, I'm looking at adding Meson support to > Continuous, as part of a larger rework of the manifest file to adapt > to the Flatpak builder manifest format; that will take time, though, > so in the interim it'd be great if we didn't have to ship a patch for > every project, when the alternative is simply dropping a script into > the project's top-level. > > Ciao, > Emmanuele. > > [1]: https://github.com/cgwalters/build-api > [2]: https://github.com/ebassi/graphene/blob/master/configure > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: For projects switching to Meson *only*
Hello Emmanuele, Would be fine if the maintainer does the patch for continuous instead of doing the build-API? Carlos Soriano Original Message Subject: For projects switching to Meson *only* Local Time: 27 April 2017 10:45 AM UTC Time: 27 April 2017 08:45 From: eba...@gmail.com To: Desktop Development List <desktop-devel-list@gnome.org> Hi everyone; since maintainers have started switching to Meson for the development cycle (awesome!) I'd like to ask for a favour: if you're dropping autotools entirely, could you please add a `configure` wrapper script that conforms to the build-api[1] that GNOME Continuous uses? A simple script is available here[2], and it has nice properties, like being able to work with a simple: ./configure make sudo make install which makes distributors and integrators happy. Before you ask: yes, I'm looking at adding Meson support to Continuous, as part of a larger rework of the manifest file to adapt to the Flatpak builder manifest format; that will take time, though, so in the interim it'd be great if we didn't have to ship a patch for every project, when the alternative is simply dropping a script into the project's top-level. Ciao, Emmanuele. [1]: https://github.com/cgwalters/build-api [2]: https://github.com/ebassi/graphene/blob/master/configure -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
For projects switching to Meson *only*
Hi everyone; since maintainers have started switching to Meson for the development cycle (awesome!) I'd like to ask for a favour: if you're dropping autotools entirely, could you please add a `configure` wrapper script that conforms to the build-api[1] that GNOME Continuous uses? A simple script is available here[2], and it has nice properties, like being able to work with a simple: ./configure make sudo make install which makes distributors and integrators happy. Before you ask: yes, I'm looking at adding Meson support to Continuous, as part of a larger rework of the manifest file to adapt to the Flatpak builder manifest format; that will take time, though, so in the interim it'd be great if we didn't have to ship a patch for every project, when the alternative is simply dropping a script into the project's top-level. Ciao, Emmanuele. [1]: https://github.com/cgwalters/build-api [2]: https://github.com/ebassi/graphene/blob/master/configure -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list