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 Catanzaro <mike.catanz...@gmail.com> wrote: > > On Thu, Apr 27, 2017 at 4:11 AM, Iain Lane <i...@orangesquash.org.uk> 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
