Hi Greg,
Replies are a bit out-of-order, but hopefully logical. > From: Greg Troxel <[email protected]> > Assuming http://www.libtiff.org/build.html is correct > it more or less says ANSI C and doesn't mention C++. > But the pkgsrc package says C++ is needed and adds --enable-cxx. I'm afraid that link is around 19 years out of date (!!) I have no clue who owns that domain or why it's hosting such an ancient copy of the documentation, but it's not owned by anyone here that I'm aware of. Would be nice if it could be pointed to the current documentation. http://www.simplesystems.org/libtiff/build.html or https://libtiff.gitlab.io/libtiff/build.html are current (also on maptools.org) http://rleigh.gitlab.io/libtiff/build.html is a staged copy of a replacement manual (the content is the same) > I am really only trying to suggest that specifying the prereqs clearly is the most important thing, more than having a list of "supported platforms". I agree that the prerequisites should be clearly specified. 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. 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. 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 agree that this can get excessive. I would therefore say that the oldest reasonable system anad the newest are both good to have and the ones in the middle are likely skippable. 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 should say that I didn't mean that 20.04 was super important in its own right. But I think it's a reasonable proxy for dependencies of that era, as is 18.04. So if the build no longer works on them, that's big news, and good to detect early. Yes, I got that point. It's a good reason to use an earlier release if we want to be testing on the GCC of that "era". But we would need to establish specifically what those criteria are. > (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). Kind regards, Roger _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
