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

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

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.
2. e.g.

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.

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.


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