Using Meson for build system

[TingPing]

Just wanted to start a discussion on if this would be wanted. Meson is a relatively new build system whose selling points over Autotools are speed, portability, correctness, and simplicity.

A decent amount of other projects have made the switch within Gnome: https://github.com/mesonbuild/meson/wiki/Users (not all inclusive)

Since Enchant is such a small codebase this would just be a few hundred lines of build files. Some projects have opted to supporting both until Meson is more widely prevalent but this could replace both the hand made Visual Studio files and Autotools in the end.

[rrthomas]

My own point of view is that I know autotools, it works, and I don't particularly want to learn a new system at present.

I would also point out that the autotools have advanced considerably in recent times, and comparisons with other systems are often outdated.

Having said that, I agree that they are hard to learn and debug.

If someone else made a Meson build system for libenchant that was complete, so it was possible to do a proper evaluation, I would be very happy to compare them.

I admit that this is a big request, but if Meson is better, this should be obvious at an early stage (especially if a careful survey is made of all the features we require in the build system), so that it should be a project that is likely to succeed (and hence not be wasted work).

[TingPing]

This has been pushed to https://github.com/TingPing/enchant/tree/meson

To install meson either get it from the distro if new enough or install ninja and pip install --user meson.

To run:

meson build && cd build
ninja
ninja test
ninja install

The main work left is add options for directories. I also didn't touch the OSX plugin yet. Everything else should work.

For some performance comparisons including configure and build: Meson takes 1 second, Autotools takes 20.

For LoC: Meson is ~400, Autotools is ~800 if you ignore m4 files.

I've not tested it on Windows but it should work with minimal changes.

[TingPing]

@rrthomas You get a chance to check out that Meson branch yet, or would you like me to just open a PR where we can discuss it further?

[rrthomas]

I'm planning to get 1.6.1 out first, then I'll consider Meson as part of 2.0.

[rrthomas]

I have just completed a thorough overhaul of the Autotools build system. The entire thing, including bootstrap.conf and configure.ac, plus all the Makefile.ams, is now 428 LoC (counted with cloc; 653 lines of text). The only non-3rd-party, non-generated code this excludes is my updates to gnulib's manywarnings module, in gl/m4, which I've already submitted upstream and expect to be included in gnulib soon.

Using cloc (which seems fair here) I count 380 LoC for the current Meson build system (436 lines of text). So it's still shorter, but doesn't yet support dictionary directories or Windows.

(Currently the autotools build system does not support OS X either, in the sense that the AppleSpell backend is never built. I will fix that or file an issue.)

Since we're now using gnulib, switching to Meson might be harder. Also, at present it's not a big gain in terms of code size. Meson does seem to be quite a bit faster, but I'm not sure that's important (for development, rebuilding after a small change is fast with autotools too; and it seems to me that Meson is not probing the build system as much: for example, the autotools build system checks that the compiler warning flags actually work. Also, a lot of system-specific features are tested and patched on a wide range of systems we'd like to work on (e.g. various BSDs).

There's also one way to speed up the autotools build and reduce code size that I've not tried yet: make it non-recursive.

So I'm not currently convinced it's worth it to switch, but I welcome further evidence and discussion.

[rrthomas]

Closing this for now, as I don't think it's currently worth the effort; there's plenty to do that directly benefits functionality and robustness, so I'll concentrate on that.

[xclaesse]

There are a few other advantages of meson:

• Builds out of the box on Windows/MSVC, no need for huge msys2 environment.
• Makes easy to build libenchant as subproject of another Meson project. That simplify a lot building applications on anything other than a recent linux distro, on platforms where we can't just install libenchant-dev to build apps.

See my blog post how easy it makes to build a GTK4 application on Windows, for example:
https://www.collabora.com/news-and-blog/blog/2021/03/18/build-and-run-gtk-4-applications-with-visual-studio/

[danyeaw]

I also think it would be really nice to support meson even unofficially. gvsbuild is still using a very old version of enchant with patches to get a working build.

[rrthomas]

See #301. I would at least consider having secondary build systems maintained by other people, in the same way as providers, with the same sort of proviso that they need to be kept in some sort of working order.

On the other hand, it would be better long-term to replace the current build system; however, it would also be quite a lot of work, as it does many things. And I've had two strong proposals so far as to what that build system should be: either Meson or CMake. I don't really know how to judge that.

[danyeaw]

@rrthomas Would it be worth trying to rebase @TingPing's meson branch?

If it was me, I would go with meson just for readability alone. Either would be a nice upgrade to Autotools though.

[rrthomas]

I just want to be clear that the only work I'm offering to do in this direction is to review a new build system! I don't particularly want or need a new build system for my work as maintainer, I'm not terribly enthusiastic about build systems, and I don't know any of the systems being proposed as replacements for autotools. I am sympathetic to the desire for a faster build system that works better on non-POSIX systems, and hence am prepared to put some work in reviewing and learning how to operate and maintain one.