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

[Sam Thursfield <ssssam gmail com>]

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:
<https://git.busybox.net/buildroot/tree/support/misc/toolchainfile.cmake.in>.

Meson's works in pretty much the same way:
<https://github.com/mesonbuild/meson/wiki/Cross-compilation>

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
<https://github.com/centricular/gstreamer/> (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
<https://bugzilla.gnome.org/show_bug.cgi?id=769881>. 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