Re: For projects switching to Meson *only*

[Emmanuele Bassi <ebassi gmail com>]

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.

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