Re: For projects switching to Meson *only*

[Bastien Nocera]

On Sat, 2017-04-29 at 12:06 -0500, mcatanz...@gnome.org wrote:
> On Sat, Apr 29, 2017 at 7:45 AM, Bastien Nocera  
> wrote:
> > Are you saying you reverted jhbuild module changes, without
> > notifying
> > the committer, because there's a problem with the grilo/grilo-
> > plugins
> > handling,
> 
> I did notify the committer (Javier).
> 
> >  but you didn't file a bug against those modules?
> 
> Due to the large number of build failures we have to deal with when 
> releasing, I normally only file bugs on release day if I can't get
> the 
> modules to build at all.

I filed:
https://bugzilla.gnome.org/show_bug.cgi?id=782055
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Peter Hutterer]

On Fri, Apr 28, 2017 at 10:34:03AM +0100, Richard Hughes wrote:
> On 28 April 2017 at 01:00, Peter Hutterer  wrote:
> > I will, but I'll keep the two parallel for at least a release or two.
> 
> I tried doing this in my projects last cycle and was a bit of a
> disaster. Pretty much any committer that added files or changed how
> the project was built, broke one of the two systems. Asking people to
> test two quite different build systems before sending patches is
> raising the bar a little too high and adding confusion. IMHO, etc.

Yeah, I can see that. 'fortunately', libinput has a continuos contributor
count of approximately 1, so I guess having all contributors test two build
systems won't be the biggest issue ;)

Cheers,
   Peter
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[mcatanzaro]

On Sat, Apr 29, 2017 at 7:45 AM, Bastien Nocera  
wrote:

Are you saying you reverted jhbuild module changes, without notifying
the committer, because there's a problem with the grilo/grilo-plugins
handling,


I did notify the committer (Javier).


 but you didn't file a bug against those modules?


Due to the large number of build failures we have to deal with when 
releasing, I normally only file bugs on release day if I can't get the 
modules to build at all.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Bastien Nocera]

On Fri, 2017-04-28 at 10:19 -0500, mcatanz...@gnome.org wrote:
> On Fri, Apr 28, 2017 at 4:40 AM, Bastien Nocera  
> wrote:
> > On Fri, 2017-04-28 at 00:37 -0500, mcatanz...@gnome.org wrote:
> > >  On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer
> > >   wrote:
> > >  > 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
> > > 
> > >  Here's a request for maintainers who are supporting both meson
> > > and
> > >  Autotools: please consider adding the meson build files to your
> > >  release
> > >  tarballs (add them to EXTRA_DIST) if you want people to actually
> > > use
> > >  the meson build system. You don't have to, but it'd be nice.
> > > 
> > >  For people helping maintain the jhbuild modulesets, please do
> > > not
> > >  switch modules to use meson until the meson build files have
> > >  appeared
> > >  in a release tarball, or you're confident they will appear in
> > > the
> > >  next
> > >  tarball. (Unless Autotools support has already been dropped, in
> > >  which
> > >  case maintainers, please follow the GNOME release cycle in
> > > making
> > >  your
> > >  next release!) This will reduce the amount of manual hacking
> > >  required
> > >  to produce release modulesets that actually build. I've
> > > temporarily
> > >  switched GStreamer and Grilo back to using Autotools for this 
> > > reason.
> > 
> > What was the problem with Grilo's meson support?
> > 
> > We have a bug opened for a regression with the 0.4.0 version, but
> > the
> > meson build works as expected in jhbuild.
> > 
> > Cheers
> 
> Problem with grilo is there are no meson build files in the latest 
> release tarballs, and the modulesets need to work when converted to 
> tarballs for our release process.

Are you saying you reverted jhbuild module changes, without notifying
the committer, because there's a problem with the grilo/grilo-plugins
handling, but you didn't file a bug against those modules?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[mcatanzaro]

On Fri, Apr 28, 2017 at 4:40 AM, Bastien Nocera  
wrote:

On Fri, 2017-04-28 at 00:37 -0500, mcatanz...@gnome.org wrote:

 On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer
  wrote:
 > 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

 Here's a request for maintainers who are supporting both meson and
 Autotools: please consider adding the meson build files to your
 release
 tarballs (add them to EXTRA_DIST) if you want people to actually use
 the meson build system. You don't have to, but it'd be nice.

 For people helping maintain the jhbuild modulesets, please do not
 switch modules to use meson until the meson build files have
 appeared
 in a release tarball, or you're confident they will appear in the
 next
 tarball. (Unless Autotools support has already been dropped, in
 which
 case maintainers, please follow the GNOME release cycle in making
 your
 next release!) This will reduce the amount of manual hacking
 required
 to produce release modulesets that actually build. I've temporarily
 switched GStreamer and Grilo back to using Autotools for this 
reason.


What was the problem with Grilo's meson support?

We have a bug opened for a regression with the 0.4.0 version, but the
meson build works as expected in jhbuild.

Cheers


Problem with grilo is there are no meson build files in the latest 
release tarballs, and the modulesets need to work when converted to 
tarballs for our release process.


By the way, I'm told the latest GStreamer tarballs are unproblematic, 
so I switched it back to Meson. Turns out I just forgot to remove our 
GStreamer version limit that we had used for 3.24. We don't have any 
way to automatically handle unstable versions of dependencies that 
aren't using the GNOME release cycle but which we still want to build 
from git usually. :(


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Bastien Nocera]

On Fri, 2017-04-28 at 00:37 -0500, mcatanz...@gnome.org wrote:
> On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer 
>  wrote:
> > 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
> 
> Here's a request for maintainers who are supporting both meson and 
> Autotools: please consider adding the meson build files to your
> release 
> tarballs (add them to EXTRA_DIST) if you want people to actually use 
> the meson build system. You don't have to, but it'd be nice.
> 
> For people helping maintain the jhbuild modulesets, please do not 
> switch modules to use meson until the meson build files have
> appeared 
> in a release tarball, or you're confident they will appear in the
> next 
> tarball. (Unless Autotools support has already been dropped, in
> which 
> case maintainers, please follow the GNOME release cycle in making
> your 
> next release!) This will reduce the amount of manual hacking
> required 
> to produce release modulesets that actually build. I've temporarily 
> switched GStreamer and Grilo back to using Autotools for this reason.

What was the problem with Grilo's meson support?

We have a bug opened for a regression with the 0.4.0 version, but the
meson build works as expected in jhbuild.

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Richard Hughes]

On 28 April 2017 at 01:00, Peter Hutterer  wrote:
> I will, but I'll keep the two parallel for at least a release or two.

I tried doing this in my projects last cycle and was a bit of a
disaster. Pretty much any committer that added files or changed how
the project was built, broke one of the two systems. Asking people to
test two quite different build systems before sending patches is
raising the bar a little too high and adding confusion. IMHO, etc.

Richard
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[mcatanzaro]

On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer 
 wrote:
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


Here's a request for maintainers who are supporting both meson and 
Autotools: please consider adding the meson build files to your release 
tarballs (add them to EXTRA_DIST) if you want people to actually use 
the meson build system. You don't have to, but it'd be nice.


For people helping maintain the jhbuild modulesets, please do not 
switch modules to use meson until the meson build files have appeared 
in a release tarball, or you're confident they will appear in the next 
tarball. (Unless Autotools support has already been dropped, in which 
case maintainers, please follow the GNOME release cycle in making your 
next release!) This will reduce the amount of manual hacking required 
to produce release modulesets that actually build. I've temporarily 
switched GStreamer and Grilo back to using Autotools for this reason.


Thanks,

Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Peter Hutterer]

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

Re: For projects switching to Meson *only*

[Michael Catanzaro]

On Thu, Apr 27, 2017 at 9:24 AM, Emmanuele Bassi  
wrote:

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?


Yes, and my apologies for failing to do this yesterday when I switched 
over Epiphany. I even left JHBuild broken. Maintainers, please don't do 
that. :)


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Emmanuele Bassi]

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

Re: For projects switching to Meson *only*

[Michael Catanzaro]

On Thu, Apr 27, 2017 at 4:11 AM, Iain Lane  
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?

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.


This compatibility issue seems like a very good argument for shipping 
the "compatibility" script in Continuous patches rather than 
application repositories.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Iain Lane]

Hiya,

Apologies for any ignorance about the scope and intent of the build API.

On Thu, Apr 27, 2017 at 09:45:04AM +0100, Emmanuele Bassi wrote:
> Hi everyone;
> A simple script is available here[2], and it has nice properties, like
> being able to work with a simple:
> 
>   ./configure
>   make
>   sudo make install
> 
> which makes distributors and integrators happy.
> […]
> [2]: https://github.com/ebassi/graphene/blob/master/configure

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?

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.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Emmanuele Bassi]

The issue is not writing a simple patch: it takes me about 90 seconds
of my life to copy the file, create a commit, format-patch it, and add
the patch to gnome-continuous.

The whole point would be to avoid adding a patch to Continuous.

Additionally, conforming to the build-api is a nice transitional tool
for distributors that are still trying to catch up to Meson.

Ciao,
 Emmanuele.


On 27 April 2017 at 09:48, Carlos Soriano  wrote:
> Hello Emmanuele,
>
> Would be fine if the maintainer does the patch for continuous instead of
> doing the build-API?
>
> Carlos Soriano
>
>  Original Message 
> Subject: For projects switching to Meson *only*
> Local Time: 27 April 2017 10:45 AM
> UTC Time: 27 April 2017 08:45
> From: eba...@gmail.com
> To: Desktop Development List 
>
> Hi everyone;
>
> since maintainers have started switching to Meson for the development
> cycle (awesome!) I'd like to ask for a favour: if you're dropping
> autotools entirely, could you please add a `configure` wrapper script
> that conforms to the build-api[1] that GNOME Continuous uses?
>
> A simple script is available here[2], and it has nice properties, like
> being able to work with a simple:
>
> ./configure
> make
> sudo make install
>
> which makes distributors and integrators happy.
>
> Before you ask: yes, I'm looking at adding Meson support to
> Continuous, as part of a larger rework of the manifest file to adapt
> to the Flatpak builder manifest format; that will take time, though,
> so in the interim it'd be great if we didn't have to ship a patch for
> every project, when the alternative is simply dropping a script into
> the project's top-level.
>
> Ciao,
> Emmanuele.
>
> [1]: https://github.com/cgwalters/build-api
> [2]: https://github.com/ebassi/graphene/blob/master/configure
>
> --
> 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
>
>



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

Re: For projects switching to Meson *only*

[Carlos Soriano via desktop-devel-list]

Hello Emmanuele,

Would be fine if the maintainer does the patch for continuous instead of doing 
the build-API?

Carlos Soriano

 Original Message 
Subject: For projects switching to Meson *only*
Local Time: 27 April 2017 10:45 AM
UTC Time: 27 April 2017 08:45
From: eba...@gmail.com
To: Desktop Development List 

Hi everyone;

since maintainers have started switching to Meson for the development
cycle (awesome!) I'd like to ask for a favour: if you're dropping
autotools entirely, could you please add a `configure` wrapper script
that conforms to the build-api[1] that GNOME Continuous uses?

A simple script is available here[2], and it has nice properties, like
being able to work with a simple:

./configure
make
sudo make install

which makes distributors and integrators happy.

Before you ask: yes, I'm looking at adding Meson support to
Continuous, as part of a larger rework of the manifest file to adapt
to the Flatpak builder manifest format; that will take time, though,
so in the interim it'd be great if we didn't have to ship a patch for
every project, when the alternative is simply dropping a script into
the project's top-level.

Ciao,
Emmanuele.

[1]: https://github.com/cgwalters/build-api
[2]: https://github.com/ebassi/graphene/blob/master/configure

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