I’ve tried to add Meson build system to MyHTML, but fail. They prefer the one is used today. That’s OK.
Support two build systems increase burden on project maintenance, this is the main reason to reject my pull request and is OK. As for GXml, we have both Autotools and Meson. I’m trying to keep both in sync, as soon as a new file is added, but you may forget one or the other.
While I use GXml on my Windows programs, I need to make sure it will work properly out of the box, like Autotools does, before to remove the later.
The main problem about Meson is: it is moving a lot, with new features added in resent versions; so they are not immediately available, i.e. in Windows through MSYS2. Just need to wait until Meson declares a LTS, or something like that, and is included by default in distributions and in MSYS2.
Extra effort to maintain both build systems makes the difference in my Vala development procedure: Code, Code Test, Run Test, Fix Code, Confirm Test Pass. This process have gained a boost in productivity, because Meson compile time and the way to run tests; so less time compiling, means more time Coding.
4 thoughts on “Support more than one Build System”
Do not use meson
For what it’s worth, you don’t need to wait for distros to ship Meson before using it. You can use `pip3` to do the installation and especially on Windows that is the recommended way to do it since that allows you to use it with any environment (MSYS, MSYS2, MSVC, etc).
If you have problems using Meson to do release tarballs, please come to #mesonbuild on Freenode and complain to us, and we’ll try to help and/or fix whatever is broken in Meson. 🙂
During this summer I’ve been involved in some meson ports of gnome ecosystem (~20). Here are some raw numbers regarding those ports:
– 6 ports have been accepted, of which 4 have even removed autotools.
– 3 ports have shown interest in meson and maintainers have given some indications.
– 2 ports have received some feedback, though, I’m not sure if they are actually interested.
– 3 ports are unlikely to happen. 1 of them because is deprecated, though another not deprecated package depends on it, and the other 2 unless some maintenance conditions are met.
– 6 of them haven’t received any feedback at all, and I actually don’t know what will happen to them :(.
Most of the maintainers are not used to meson and have some reticences about it. The burden of having to maintain two build system is another issue.
MSYS2 should already have an up to date meson/ninja.