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

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

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

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?


[@] ebassi []

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]