Re: For projects switching to Meson *only*

[Peter Hutterer <peter hutterer who-t net>]

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 catanzaro gmail com> wrote:
> > On Thu, Apr 27, 2017 at 4:11 AM, Iain Lane <iain 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