Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Nicolas Dufresne]

Le lundi 10 octobre 2016 à 22:51 +0900, Tristan Van Berkom a écrit :
> 
> I would caution against using only JHBuild as a metric for Meson's
> maturity. Rather I would recommend starting at the lower end of the
> stack, say try to port glib/GTK+ over to use Meson in a wip branch,
> and
> then see how that withstands a cross compile to arm in a wip branch
> against Yocto poky master.

Glib meson branch can be found here:

https://github.com/centricular/glib

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

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Bastien Nocera]

On Thu, 2016-10-13 at 10:18 -0500, Michael Catanzaro wrote:
> On Thu, 2016-10-13 at 11:53 +0100, Sam Thursfield wrote:
> > Would a GNOME-goal to ensure that every project follows the Build
> > API
> > help
> > here?
> 
> 
> What do the meson developers think about the Build API?
> 
> I think I would not support such a goal. I do not want to add a
> boilerplate fake configure script to my project, nor a fake Makefile
> to
> a project that doesn't use make at all. I want to have fewer build
> system files to worry about, not more.

This "build API" is also what Flatpak expects. It's also baked in a
number of package build systems.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Michael Catanzaro]

On Thu, 2016-10-13 at 11:53 +0100, Sam Thursfield wrote:
> Would a GNOME-goal to ensure that every project follows the Build API
> help
> here?

What do the meson developers think about the Build API?

I think I would not support such a goal. I do not want to add a
boilerplate fake configure script to my project, nor a fake Makefile to
a project that doesn't use make at all. I want to have fewer build
system files to worry about, not more.

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

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Nirbheek Chauhan]

Hello,

On Thu, Oct 13, 2016 at 4:23 PM, Sam Thursfield  wrote:
> I agree with the sentiments above that Meson isn't quite ready for this
> yet. I've tried Meson out for 2 projects (Tracker and Rhythmbox) and in
> both cases there have been several patches needed to Meson, some of
> which are still unfinished.
>
> Many people other people seem to be trying out Meson already, which is
> good, and suggests we don't need to do anything further right now to
> encourage people to try it out.
>

Yes, the GNOME module in Meson has had several improvements merged,
and more in the pipeline. Thanks for your patches!

We've been hard at work to make everything work smoothly for GNOME
projects, and have had a lot of interest; particularly from the Vala
folks. It's quite encouraging! Our goal is to have GNOME and Vala
support working flawlessly out of the box ASAP, and people coming and
telling us what they need has been a great help in that regard.

If you are thinking about trying Meson out and need help, hop on to
#mesonbuild on Freenode and find us. :-)

PS: We'd really like some help in making our documentation more newbie
friendly too.

> There are GStreamer build instructions using Meson at
>  (and /gst-plugins-*/) which
> seem pretty complete and I believe they're already being used to
> cross-compile GStreamer to Windows.
>

Just bunch of small corrections. The GStreamer Meson build files have
been merged upstream (alongside Autotools), so it is recommended that
you get them from there:

https://cgit.freedesktop.org/gstreamer/gstreamer/

+ /gst-plugins-{base,good,bad,ugly}, etc.

We also have a git repo that uses Meson's subproject feature to build
gstreamer + plugins in one tree in one go:
https://github.com/thiblahute/gst-all . This is the recommended way of
building GStreamer with Meson on Linux using the system-install
dependencies.

We have our own "jhbuild/continuous-equivalent" called Cerbero that is
used for building GStreamer in other configurations. The default build
used there is still Autotools. For that, we have a branch
(https://github.com/centricular/cerbero) that can build gstreamer +
plugins on Linux, on native Windows, and can cross-compile to Windows
on Linux.

> For GTK+, there are preliminary build instructions for GTK+ at
> . I guess it would be
> a few days work to make these nearly-complete. So I think Meson is close
> to being able to pass that test already.
>

There's also a Glib repository with Meson build files
(https://github.com/centricular/glib), but just like the GTK+ build
it's not complete yet, and we're working on making it have
feature-parity with the Autotools build and the Visual Studio project
files shipped with the project. It's just a matter of going over the
Autotools build files line by line and checking that everything has
been translated over.

Cheers,

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

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Sam Thursfield]

On 05/10/16 15:39, Michael Biebl wrote:
>As much as I hate autotools and its arcane syntax, it does bring
>uniformity and consistency.
>Atm I'm counting waf (for some non-core modules), autotools, cmake and
>some are discussing to use meson/ninja.

>So while I'm not tied to autotools, I would hate to see if every
>modules maintainer chooses his/her own build system of choice. This
>makes it really cumbersome as downstream/integrator.

Would a GNOME-goal to ensure that every project follows the Build API help
here?

I feel that should be tied up with improvements to build-api.git that make it
trivial for CMake and Meson projects to achieve Build API compatibility
provided they follow certain conventions.

On 10/10/16 9:49, Sebastian Geiger (Lanoxx) wrote:
> This would of course mean that we already know meson will be the build
> system of choice and that it fits the needs of all modules. Of course
> individual module maintainers would still be free to make a different
> choice or to stick with autotools but we would at least have something
> to motivate the migration, to track its status across all modules and
> it would be a push to towards some level of consistency. Also we could
> collect some best practices from modules that have already done the
> conversion on a Gnome Goal page.

I agree with the sentiments above that Meson isn't quite ready for this
yet. I've tried Meson out for 2 projects (Tracker and Rhythmbox) and in
both cases there have been several patches needed to Meson, some of
which are still unfinished.

Many people other people seem to be trying out Meson already, which is
good, and suggests we don't need to do anything further right now to
encourage people to try it out.

Later on, I agree as well that we should encourage switching away from
Autotools, and recommend (but not mandate) Meson as its replacement.

Both CMake and Meson are much faster than Autotools (like, 3 second
vs. 30 second reconfigure time); so as developers & system integrators
we get a clear benefit.

When writing build instructions I definitely prefer Meson over CMake,
due to CMake's confusing failure cases[1], huge amount of cruft[2],
the strange preference for manually maintained FindPkg* modules over
upstream pkg-config files, and other things. However, making simple
changes to a CMake build system is pretty intuitive so as long as
someone else went through the initial pain of writing them, it's fine
:-)

1. e.g. https://samthursfield.wordpress.com/2015/11/21/
2. e.g. https://cmake.org/cmake/help/v3.4/manual/cmake-properties.7.html


On 10/10/16 at 2:51PM, Tristan Van Berkom wrote:
> I'm not familiar with Meson myself but have had to go through numerous
> headaches dealing with CMake ported projects which tended to build
> well on the maintainers computer but not on mine, or not withstand to
> a cross compile properly. CMake (and it's userbase) is/are starting to
> be mature and these problems are fewer and further between.

CMake has had decent cross-compile support for a while, you just create
a 'toolchain file'. Here's the toolchain file template used by the
Buildroot build
system for example:
.

Meson's works in pretty much the same way:


The state of the art for cross compilation with Autoconf is also to
manually pass in all the config flags that it can't figure out for
itself, e.g.

  http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/temp-system/bash.html
  
http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/temp-system/coreutils.html
  http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/temp-system/tar.html

> I would caution against using only JHBuild as a metric for Meson's
> maturity. Rather I would recommend starting at the lower end of the
> stack, say try to port glib/GTK+ over to use Meson in a wip branch, and
> then see how that withstands a cross compile to arm in a wip branch
> against Yocto poky master.

Agreed, that seems a good test (although I'd test with Buildroot :-).

There are GStreamer build instructions using Meson at
 (and /gst-plugins-*/) which
seem pretty complete and I believe they're already being used to
cross-compile GStreamer to Windows.

For GTK+, there are preliminary build instructions for GTK+ at
. I guess it would be
a few days work to make these nearly-complete. So I think Meson is close
to being able to pass that test already.

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

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Tristan Van Berkom]

On Mon, 2016-10-10 at 08:39 -0500, Michael Catanzaro wrote:
> On Mon, 2016-10-10 at 10:04 +0100, Philip Withnall wrote:
> > 
> > I don’t think we’ve ported enough modules as testbeds yet. Meson is
> > too new
> > to jump into encouraging everyone to port GNOME modules en-masse.
> > 
> > Maybe the goal could be proposed in 6 months once Meson has matured
> > a
> > bit
> > more and more modules have dogfooded it?
> 
> Yeah. I've been looking at Meson recently and it looks really nice,
> but
> right now not much is using it in JHBuild, just GStreamer and, as of
> yesterday, libhttpseverywhere. Let's port a couple more modules and
> give it some months before we decide to recommend it project-wide.
> This
> also gives Meson some more time to mature.

I'm not familiar with Meson myself but have had to go through numerous
headaches dealing with CMake ported projects which tended to build well
on the maintainers computer but not on mine, or not withstand to a
cross compile properly. CMake (and it's userbase) is/are starting to be
mature and these problems are fewer and further between.

I would caution against using only JHBuild as a metric for Meson's
maturity. Rather I would recommend starting at the lower end of the
stack, say try to port glib/GTK+ over to use Meson in a wip branch, and
then see how that withstands a cross compile to arm in a wip branch
against Yocto poky master.

If that works well I would say it's pretty much ready.

Cheers,
    -Tristan

> 
> At any rate, I have experience with working on CMake for WebKitGTK+,
> and my initial impression of meson relative to CMake is highly
> positive.
> 
> Michael
> ___
> 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: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Michael Catanzaro]

On Mon, 2016-10-10 at 10:04 +0100, Philip Withnall wrote:
> I don’t think we’ve ported enough modules as testbeds yet. Meson is
> too new
> to jump into encouraging everyone to port GNOME modules en-masse.
> 
> Maybe the goal could be proposed in 6 months once Meson has matured a
> bit
> more and more modules have dogfooded it?

Yeah. I've been looking at Meson recently and it looks really nice, but
right now not much is using it in JHBuild, just GStreamer and, as of
yesterday, libhttpseverywhere. Let's port a couple more modules and
give it some months before we decide to recommend it project-wide. This
also gives Meson some more time to mature.

At any rate, I have experience with working on CMake for WebKitGTK+,
and my initial impression of meson relative to CMake is highly
positive.

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

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Milan Crha]

On Mon, 2016-10-10 at 10:49 +0200, Sebastian Geiger (Lanoxx) wrote:
> On 05/10/16 15:39, Michael Biebl wrote:
> > So while I'm not tied to autotools, I would hate to see if every
> > modules maintainer chooses his/her own build system of choice. This
> > makes it really cumbersome as downstream/integrator.
> 
> Maybe it would make sense to introduce an official Gnome Goal that 
> encourages every module maintainer to switch over to
> meson.

Hi,
I didn't mention it earlier, but I didn't pick CMake out of blue. I've
got inspired by the projects the evolution core products depend on.

Some time ago, I touched WebKitGTK+, which uses CMake. Very recently I
helped to upstream libical-glib GNOME hosted project to libical
upstream, which also uses CMake and as I spent some time learning it
during the libical-glib work it was just a natural choice for me. I did
not want to spend more time on learning yet another build system.

No doubt, the CMake isn't perfect (I miss real post-install
steps/commands there, like to recompile gsettings schemas and icon
caches, for which I have workarounds there), but (otherwise) it works
pretty fine for me.
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Philip Withnall]

On Mon, 2016-10-10 at 10:49 +0200, Sebastian Geiger (Lanoxx) wrote:
> On 05/10/16 15:39, Michael Biebl wrote:
> 
> > 
> > As much as I hate autotools and its arcane syntax, it does bring
> > uniformity and consistency.
> > Atm I'm counting waf (for some non-core modules), autotools, cmake and
> > some are discussing to use meson/ninja.
> > 
> > So while I'm not tied to autotools, I would hate to see if every
> > modules maintainer chooses his/her own build system of choice. This
> > makes it really cumbersome as downstream/integrator.
> Maybe it would make sense to introduce an official Gnome Goal that 
> encourages every module maintainer to switch over to
> meson.
> 
> This would of course mean that we already know meson will be the build 
> system of choice and that it fits the
> needs of all modules. Of course individual module maintainers would 
> still be free to make a different choice or to stick with autotools but 
> we would at least have something to motivate the migration, to track its 
> status across all modules and it would be a push to towards some level 
> of consistency. Also we could collect some best practices from modules 
> that have already done the conversion on a Gnome Goal page.

I don’t think we’ve ported enough modules as testbeds yet. Meson is too new
to jump into encouraging everyone to port GNOME modules en-masse.

Maybe the goal could be proposed in 6 months once Meson has matured a bit
more and more modules have dogfooded it?

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

Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Sebastian Geiger (Lanoxx)]

On 05/10/16 15:39, Michael Biebl wrote:


As much as I hate autotools and its arcane syntax, it does bring
uniformity and consistency.
Atm I'm counting waf (for some non-core modules), autotools, cmake and
some are discussing to use meson/ninja.

So while I'm not tied to autotools, I would hate to see if every
modules maintainer chooses his/her own build system of choice. This
makes it really cumbersome as downstream/integrator.
Maybe it would make sense to introduce an official Gnome Goal that 
encourages every module maintainer to switch over to

meson.

This would of course mean that we already know meson will be the build 
system of choice and that it fits the
needs of all modules. Of course individual module maintainers would 
still be free to make a different choice or to stick with autotools but 
we would at least have something to motivate the migration, to track its 
status across all modules and it would be a push to towards some level 
of consistency. Also we could collect some best practices from modules 
that have already done the conversion on a Gnome Goal page.


Personally I would not mind if we got rid of autotools any time soon.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list