2021.01.03 10:55 "Re: [Tiff] Autotools (was: Enabling and requiring C99 language support)", by Roger Leigh

Would switching to C99 make autotools unnecessary?

I had a memorable experience with libtiff was about ten years ago. It involved some confusion with autoconf, combined with a gradual migration from 32 to 64 bit architectures. There was quite a bit of data corruption.

If you look at the changes made to configure.ac when moving to C99 (here <https://gitlab.com/rleigh/libtiff/-/compare/legacy-typedef-option...require-c99#87db583be5c13c1f7b3c958b10e03d67b6a2ca06> ) you can see we remove a huge amount of (now unnecessary) complexity from the platform introspection logic. While today this logic is to the best of my knowledge correct, it’s quite possible it had bugs in the past. With C99 and standard type usage, we can delete pretty much all of it.

Generally speaking, I don’t think that C99 is directly related to making the autotools unnecessary; they are pretty much orthogonal. However, I do think it might be worth re-examining the value the autotools provide, and considering if it is worth keeping them. We currently have four (!) separate build systems (Autotools, CMake, VMS, MSVC NMake), and maintaining four is three too many.

• Autotools is the original standard build system for UNIX platforms (Linux, BSDs, MacOS). Its maintenance has declined dramatically the last 15 years, though new releases were recently made after many years of no activity. It’s still basically stuck solving portability problems from UNIX systems of the ‘90s and early ‘00s. It was myself who added the C99 support (AC_PROG_CC_C99) to it back in the early ‘00s, and it’s changed little since.
• CMake was added later by me for providing a universal build system for all platforms (Linux, BSDs, MacOS, MSVC, Cygwin, MinGW, embedded, whatever). It is actively maintained, makes regular releases, and its support for multiple platforms is excellent, which was the motivation for adding it in the first place. It’s a single build system that aims to support everything and integrates with everything.
• VMS (configure.com) is broken for 12.5 years; Remove non-functional VMS support <https://gitlab.com/libtiff/libtiff/-/merge_requests/187> drops it entirely
• NMake (Makefile.vc) “works” but isn’t a good choice. It doesn’t allow for any platform feature detection, library detection, MSVC compiler feature detection or any of the features that Autotools or CMake offer. It also doesn’t build or run the unit tests, so you can’t validate that it built correctly.

Dropping VMS shouldn’t be a difficult choice. It’s been non-functional for over a decade with zero complaints. It has no users, and it’s dead.

NMake might have some users. The question I would have here is, have they tried out the CMake support? What is blocking moving over to CMake? The CMake support for MSVC is better in every respect. It supports all Visual Studio versions back to the ‘90s. It also supports generating NMake Makefiles should you wish to use that tool for any reason, and they will be better and more featureful than the ones we provide right now. The existing NMake Makefiles are static and can’t support the dynamic configuration CMake offers; you have to edit them by hand. My personal take on this is that they are obsoleted by CMake and have no remaining value.

The harder question is Autotools vs CMake. My personal take on this is that CMake does everything the Autotools does, and a heck of a lot more. It supports more platforms, more compilers, more support for different language standards, more build systems, has more built-in functionality, vastly better feature and library detection, and is a much better choice all around. I don’t see the Autotools adds anything of value which CMake doesn’t provide, and maintaining two complete systems in parallel is a lot of effort for little added value. Right now the two systems have identical options and behaviour. But there are some small divergences where e.g. new tests were added to Autotools and not to CMake, and that’s not a great situation to be in. I think dropping the Autotools would be a sensible choice. It’s outdated, barely maintained and obsoleted by better replacements. However, I know that there’s a lot of established familiarity with the Autotools, and many people have established workflows using them. But, is that convenience worth the cost? As for my comments on pre-C99 support; this is all cost with no benefit from my perspective.

Ideally, the build systems we support should be driven by the platforms we need to support, and by the platforms we don’t support. Right now, it’s somewhat open-ended and ill-defined. The C99 question is part of that. Just how far back is reasonable to support, and who specifically needs that support? Because collectively we all pay the cost for supporting these old platforms, even if we don’t care about them ourselves or derive any value from that support cost. We also pay a cost both in constraining what is possible within libtiff and its public interfaces, but also in the use of libtiff by third-party code which inherits these constraints. All my use of libtiff is via C++. It’s incredibly hard, if not impossible, to justify spending paid time on unnecessary make-work with zero direct benefit. The CMake build and most of my earlier libtiff contributions were all done on paid time, because it was needed to satisfy the portability requirements of the projects using libtiff. The Autotools did not satisfy the constraints and were not fit for purpose.

Kind regards,

Roger