CentOS 7 (so I guess also RHEL 7) is still supported, and uses gcc 4.8, so it would be good to have libtiff tested on that.
On Sun, 5 Jun 2022 at 14:52, Greg Troxel <[email protected]> wrote: > > <[email protected]> writes: > > > 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. > _______________________________________________ > Tiff mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/tiff >
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
