Drop autotools build

[khaledhosny]

We should drop it in the next major release. We don’t actively use it, and it is starting to be a maintenance burden.

[alerque]

I don't think "we don't actively use it" is quite accurate yet. One could wish, but..

The issue as I see it is that there a lot of distros stuck on decrepitly old versions of meson—older than the minimum supported version of Meson for Harfbuzz's build. Some of these distros have newer versions of Harfbuzz than Meson would otherwise allow them to have because the autotools builds are not limited to the autotools on the target system because the source distribution is batteries included. Given that Harfbuzz has a lovely track record of not breaking backwards compatibility is isn't uncommon to build and stuff a relatively new Harfbuzz into an otherwise aging distro release.

The most egregious examples I know of is the Amazon Linux build that sadly powers way more cloud computing things than it's prowess as a distro deserves. It's Meson is locked to 0.46.1 for ... reasons. It's Harfbuzz is fresher than that, but still a whole bushel of major versions behind.

Ubuntu is in a similar boat with their LTS releases, although now that Bionic has entered the final phase and is only an "extended" support not LTS standard support mode this is much less of an issue.

The situtation with distros and Meson has improved dramatically in the last couple years since I last made this argument in relation to HarfBuzz. CentOS and many others used to be in this boat too. Moste of the ones that still are are of diminishing value.

With autotools based source distributions it is trivial to rebuild a fresh Harfbuzz on the most delinquent system. Updating Meson on the other hand is a full fledged nightmare on these systems because of Python and other ecosystem blockages. Having to update Meson just to build Harfbuzz in a way that matches the system is a huge amount of friction by comparison.

[behdad]

Let's drop it at the same time we decide c++14 is kosher. That said, c++14 doesn't really bring many features we like to use.

My benchmark has been the oldest supported RHEL. But we know people still use gcc 4.9, so I'm a bit hesitant to remove it at this time as well.

[khaledhosny]

I compared https://repology.org/project/harfbuzz/versions with https://repology.org/project/meson/versions and I couldn’t find a distribution that has harfbuzz > 4 and meson < 0.55.0, so distributions that are likely to ever update to latest harfbuzz already have newer enough meson to build it.

[alerque]

If the distros (particularly ones with versioned releases) haven't updated already for the most part they never will. We're in agreement there. Ubuntu Bionic or Amazon Linux 1 are never getting HarfBuzz 2, much less 8.

The issues is that folks saddled with whatever project demands they run on whatever relic of a system their enterprise is stuck on do (sometimes) have the option of building using a newer version of Harfbuzz, even if it is in user-land or project scoped. A fresh user build version can pretty easily be used to override the libraries used for a specific project. That's the scenario where it is important that the build tooling available on these decrepit distros be able to build fresh libraries for their own use.

[khaledhosny]

Latest meson is pip install meson away, so I’m not convinced it is a major hurdle. One can even build HarfBuzz with only a C++ compiler: c++ --std=c++11 -shared -o libharfbuzz.so src/harfbuzz.cc.

Otherwise the line of argument here means we can never drop autotools build, because there will always be someone somewhere using some ancient enterprise Linux system that is supported for two centuries and never gets any new versions of anything. If we are never going to drop autotools, why did we introduce meson then? Autotools was good enough for building HarfBuzz and we had no issues with.

[khaledhosny]

My benchmark has been the oldest supported RHEL. But we know people still use gcc 4.9, so I'm a bit hesitant to remove it at this time as well.

RHEL has devtoolset that provides latest versions of GCC.

[debohman]

Note that ICU-75 requires c++17.