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