2021.01.01 19:31 "[Tiff] Enabling and requiring C99 language support", by Roger Leigh

2021.01.03 16:11 "Re: [Tiff] Autotools (was: Enabling and requiring C99 language support)", by Bob Friesenhahn

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.

You are talking about logic that I added a long time ago.

Modern Autoconf supports rather simple sized-type checks which do use types from stdint.h if it is available:

https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#Particular-Types

If we were not concerned about possible size type changes ('long' vs 'long long' for the 64-bit size type in 64-bit builds), then these macros would be trivial to paste in and use.

"Autotools" consists of up to three (or sometimes four) different packages. The Automake part has seen many modern releases which have not resulted in any effort for us. Autoconf has recently made a major release and should make a follow-on "fixup" release soon. Autoconf has been updating continually (in its git repository) to solve today's portability problems and removing useless historic tests. The problem was completely with finding someone to get a release out.

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

Using 'git log' on configure.ac and Makefile.am I rapidly see that the effort expended by maintaining the Autotools-based build is greatly exaggerated. Much of the recent (last five years) work was to integrate 'cmake' into the build and to improve support in the 'port' directory. The Autotools-based build just sits there and works.

I am not sure what you are basing the statements about "more platforms" and "more compilers" on.

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.

"Cost" is always more convenient when others are paying. If we remove Autotools support then we will be inflicting cost on others.

Ideally, the build systems we support should be driven by the platforms we need to support, and by the platforms we don’t support.

What non-defunct platforms do we not support and which platforms do we need to 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.

I certainly agree that the writing is on the wall that environments not reasonably supporting C'99 stdint.h, inttypes.h, and "printf" formatters will not be supportable in modern software. Even Microsoft eventually realized that. For example, if libraries that libtiff depends on require C'99 stdint.h, then libtiff inherits this requirement.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt