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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
