On Wed, 2022-05-04 at 08:17 -0700, Per Bothner wrote: > On 5/4/22 05:07, Michael Orlitzky wrote: > > The trade-off you get for writing m4 is that the build system produced > > by autotools doesn't require you to have autotools installed, and > > instead uses only a portable subset of standard system tools. > > I think this is a very minor benefit: > (1) To build a project from source you need to have verious development tools installed. > The difference between "requisites are make, gcc, yacc, and xxx" vs > "requisites are make, CMake, gcc, yacc, and xxx" seems pretty minor. It's not just "CMake" that you need though, it's a new enough version of CMake that has all the features you use but is also backwards- compatible with everything else you want to build. ClamAV for example now requires a version of CMake that many people on LTS distros don't have. Granted it's not a huge problem in practice, but it does introduce a chicken-and-egg problem for end users where there need not be one, and constitutes a fundamental design flaw in most of the proposed replacements. > (2) These days, how often do people build from a source "release"? > I'm more likely to build from a git clone. And I believe best practice > is to not include autotools-generated scripts in the repository, > but instead add 'autoreconfig -i' as an initial first step. There are still a lot of users with skill levels between "only uses binary packages" and "willing to install and use git," and the releases are easier for them. Releases avoid those version incompatibilities that affect CMake: autoconf-2.7x being needed for runstatedir, for example. And when done right, a project's releases will actually be tested, making them more reliable than whatever half-baked evolutionary dead-end HEAD points to today. Finally, using the releases means that the user doesn't need to know the phrase "autoreconf -fi", which is more important than it sounds.
