Re: For projects switching to Meson *only*

2017-04-28 Thread 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*

2017-04-28 Thread 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*

2017-04-28 Thread 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: GNOME Build situation and BuildStream

2017-04-28 Thread Sébastien Wilmet 
On Thu, Apr 27, 2017 at 11:21:37PM +0900, Tristan Van Berkom wrote:
> On Thu, 2017-04-27 at 14:41 +0200, Sébastien Wilmet wrote:
> [...]
> > With jhbuild, when we enter into a jhbuild shell we are still in the
> > same directory, usually inside the git repository. With builddir ==
> > srcdir we have all the files that we can directly open with our
> > preferred text editor. When we open a new terminal tab, we are in the
> > same directory where we are able to 1) do git commands 2) building
> > (with
> > recursive make) 3) launching executables 4) editing files, etc.
> > 
> > With BuildStream, will it be similar?

[...]

> So, this is a little bit fiddly compared to working entirely within one
> build sandbox, only because you really need to exit and enter a sandbox
> environment when you want to try something out, otherwise it's snappy
> (and maybe a convenience command to say "build + shell" in one go could
> reduce a bit of typing).
> 
> On the bright side, you never ever trust your host environment for
> anything, except for a display server and session bus in the case that
> you use `bst shell` to run things.

OK, thanks for your detailed explanation.

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