<[email protected]> writes: > These are all good points. As you said, it all comes down to supporting > what is documented. Unfortunately, that isn't too clear, and having a > reasonable set of requirements properly agreed on and documented would make > the scope for CI testing clearer.
Thanks for the detailed comments. I will quote somewhat sparingly. > So I'm not averse to extending the coverage at all, but I do want to keep it > manageable. 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. > The main thread with all of these is that they are either rolling releases > building against a recent toolchain, or they are built against a recent > toolchain and then frozen for the lifetime of a distribution's major > release. What we don't have is building of a new libtiff release on an > older platform (for the most part). It ends up causing ABI breaks on LTS > releases when it conflicts with the system copy. Look at pylibtiff for an > example of that. So testing on current platforms is most beneficial for > ensuring that all of these consumers are getting a working release. That's fair about what most people do, but two things: While using new tiff on old GNU/Linux has to be done with care, someeone building it and other things that use it in a different prefix is reasonable, and we shouldn't let that break without knowing, especially if the compiler requirements are met. The LTS/rolling dichotomy seems accurate for GNU/Linux, but in BSD package management and I think the macOS ones, a number of tools come from "base system", especially compiler. There is then a mix of things that feel mostly-LTSish at the 3-4 year level, and things that are up to date. Building pkgsrc on NetBSD 8 uses oldish gcc (7), but other things tiff needs are from pkgsrc and mostly recent. > The other use case would be direct embedding of libtiff as a third-party > library within a larger project, or hand-building libtiff and using it > within other projects. This is common in proprietary projects. This is > more difficult to support since we're both unpaid volunteers and we have no > insight into what people are actually using. Sure. > I'm totally on board with adding e.g. Ubuntu 20.04 back and maybe back to > 18.04 as well. However, we do need to be somewhat restrained in how many > jobs we have in total, and which build system we test for each platform. I > would *love* to have some data on which GCC versions people are using, so > that we have some evidence to justify what we are committing to support, > rather than blindly supporting old systems "just because". If our primary > userbase isn't even using new versions of libtiff on older systems, the > cost:benefit would be low. 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. (It's also clear that the POSIX world and the Windows world are pretty much entirely separate.) > Once the new sphinx docs (rst-docs branch) are merged, I would be very happy > if we were to add a "supported platforms" page to the docs which details > this properly. It would be great to gather comments. I created > https://gitlab.com/libtiff/libtiff/-/issues/430 for this, so if anyone wants > to contribute any data, please feel free. There is "supported platforms" as a list, and there is "documented build requirements". As an pretty-old but not ancient platform, I just built 4.4.0 on NetBSD 8/i386 with gcc 7 and that was ok. For example, I think that means compiler supporting C89 and C++03, and specifically one of gcc >= 7 [or maybe earlier) [more] (and as an aside I think this should be in a text readme in the sources; I just ran into not being able to figure out the dependencies when looking at sources in a command-line only environment on an old build machine which does not come close to having a browser, and README didn't have a URL for the build instructions online. 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 am really only trying to suggest that specifying the prereqs clearly is the most important thing, more than having a list of "supported platforms".
signature.asc
Description: PGP signature
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
