2022.06.05 13:52 "Re: [Tiff] Upgrade of CI image", by Greg Troxel

http://www.simplesystems.org/libtiff/build.html or https://libtiff.gitlab.io/libtiff/build.html are current (also on maptools.org)

Would be nice to just have a link to that in README.md, since that's where somebody starting from a distribution will look.

However, often those prerequisite versions are determined by the platforms which require support, so they aren't typically specified in isolation from the platform support.

I think we have a (minor) philosopical disagreement. Traditional (old :-) GNU practice was to aim for broad compatibility and specify in the README what you needed.

I agree that when faced with "Should we bump the requirement for C++ from C++03 to C++11, therefore requiring gcc 4.9?" that this decision is made by asking "which platforms will this leave behind and do they still matter".

And, I see GNU/Linux as just one platform among many (really it's N, just as even a single BSD is multiple, but distribution x version not just version). So that leads to wanting to specify the tool/dep requirements in such a way that they are readable even if one has a system that is not on the list.

So we could say we'll support GCC7, but that might stem from saying we'll support NetBSD 8. The tool requirements have to come from somewhere.

They do have to come from somewhere, but I think they should come from documenting what is actually needed now, and then being intentional about changing that.

If it is "ANSI C", then today that should more or less be "any version of gcc". Even C++03 leads to very broad compatibility. I think tiff's requirements are very modest

We could have a policy of supporting the last n major versions of GCC or MSVC. Though GCC has changed its versioning policy recently.

I don't think there is any reason to exclude older compilers until an actual reason arises.

I am keeping separate:

- documented to require sublanguage X and thus if gcc then >= Y
- it's a bug if it doesn't work

and

- project does CI and has some standard of care to avoid breaking it

I care about the first, because projects almost never do the second on what I use.

This would be sensible, the only hard part is in making the decision of how far back to go. Just to take Ubuntu as an example, 18.04LTS goes out of maintenance in a few months (https://ubuntu.com/about/release-cycle). Given that we're not paying for extended support or being paid to support other people using it, I'd prefer not to be spending effort on supporting it, and leave 20.04 as the earliest. But it depends upon what we want out of it and how much effort we realistically want to put in to this support, and that comes back to clearly defining what those top-level requirements actually are.

I would say it's good to keep it in CI until it breaks, and then we can ask: is this change that broke it ok, or should we change the compiler requirement. To me it's all about ensuring that the code builds if the requirements in README are met, one way or the other, without undetected breakage.

(It's also clear that the POSIX world and the Windows world are pretty much entirely separate.)

Is that true? With MSVC versions from the last 8 years, you've been able to use tif_unix.c instead of tif_win32.c. And today it supports all of the C99 subset we use. All of the portability issues are gone bar a single function: getopt() from the port directory. And with the addition of the CMake build system, you have a common means of building across all platforms. As far as I can see, it's never been cleaner or simpler to support both platforms as it is today. And with "vcpkg", Windows now has a ports tree just like the BSDs. Here's the libtiff port: https://github.com/microsoft/vcpkg/tree/master/ports/tiff. You can build and install libtiff (plus all its dependencies) with a single command "vcpkg install tiff:x64-windows" (for example). It's taken some effort to make libtiff this simple to use on Windows, but it's never been quicker or simpler to use up until all these pieces came together (MSVC support for C99, CMake and vcpkg).

That is better. But what I meant is that when talking about compiler support, as you listed in CI, there are different compiler families for Windows, vs gcc and clang.