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

2021.01.02 21:47 "Re: [Tiff] Enabling and requiring C99 language support", by Roger Leigh

So I would suggest asking the question: Is anyone using libtiff and building it in an environment that does not support C99?

Yes, of course. :-)

Please note that I'm generally trailing edge and very reluctant to bump requirements. I'd be the first to object to a C++17 requirement :-) But I wonder if there are any users that build libtiff in a pre-C99 setup, especially any that would build anything else to use it.

Yes, of course. :-)

I have been using Visual Studio 2008 to build GraphicsMagick (with bundled libtiff) for quite a few years now. I did this because it was expensive software which was donated to me, and because the output was assured to run on almost all Windows systems still in use (even the ones powering digital signage displays at the airport), even if Microsoft did not want them to be running any more. Since it is a "Professional" edition there are few limitations as to what I am allowed to do with it.

It is only a relatively recent occurance that Visual Studio Community Edition has been offered for "free" use, and does not have important components for C language development degraded in some way, or does not need to be assembled from parts by the user to target C language development. Even then, the "free" Visual Studio has certain usage restrictions (https://visualstudio.microsoft.com/license-terms/mlt031819/). The "free" Visual Studio changes its characteristics whenever there is another forced update. This package is not likely suitable for commercial software development.

I agree that the updates aren’t necessarily great. But they aren’t forced; you have to opt in. And they have been pretty good for the last few years; I’ve not experienced any breaking changes for a long while. Commercial development using the community edition is permitted, but there are some restrictions based IIRC on company size. For most individuals, there won’t be a problem. For bigger companies, they probably have some licensing deal with Microsoft already.

The community edition has been available for 5 years at this point (started with VS2015); before that we had “express” editions that were similar but had less features.

Commercial software developers (many on holiday today) often deal with large complicated code bases for which following the Visual Studio upgrade treadmill is not suitable for their requirements. Instead Visual Studio upgrades are a major part of the project development schedules.

Perhaps after the holidays are over we might hear from commercial users.

I can provide one perspective, at least, though I’ll have to stay light on detail.

Old and unsupported tools means high risk. There is no vendor support, and they haven’t been tested or validated on contemporary platforms. As a result, it means the safest choice for the company is to use the currently supported version on a contemporary platform. Right now, that’s VS2019. If you were starting a brand new project, you would start with the current toolchain. Be it Visual Studio, GCC, LLVM, IAR, Keil or whatever you need. You wouldn’t start with an old and unsupported toolchain.

For products which need to be supported throughout their lifetime, it is common to freeze everything during the initial development cycle and then that validated configuration will be preserved and used throughout the support phase. Nowadays likely as a container image or virtual machine. That will include the base platform, the toolchain, and all libraries and other tools required to build, test and deploy the product. During that support phase we won’t upgrade the toolchain. But we won’t upgrade the libraries either. We will be restricted to picking up small bugfixes and security fixes only.

When it comes to using a new version of e.g. libtiff with an old toolchain, this is something you wouldn’t be doing. You’ll start off with a contemporary toolchain, and a contemporary libtiff along with all the other dependencies. “Current libtiff” with “old toolchain” is not of any interest, and I don’t think we should allow ourselves to be hobbled by the past indefinitely on the chance that someone is using an ancient setup that we can’t even pretend to support properly. Pre-C99 is just not something with any commercial value or relevance. For Visual Studio, that’s VS2013. We stopped supporting that at least three years back. All the other toolchains supported it for nearly two decades. Supporting pre-C99 usage or features is a net negative; every bit of time and effort spent supporting it is time and effort wasted on something which is not of any value at all (from this perspective).

The other relevant thing to mention here is “vcpkg”. Until a few years back, upgrading Visual Studio was a pain, because it meant rebuilding all of your dependencies from scratch, by hand, and it was painful. This is no longer a big deal, for two reasons. Firstly, they made the last three Visual Studio releases (VS2015 onward) use compatible platform toolsets (runtimes); they used the lowest common denominator runtime by default so that meant libraries didn’t need rebuilding for each version. And with vcpkg you could build all your dependencies from source in just a few minutes (it’s a copy of the BSD ports, essentially). Both of these factors have meant that upgrading to a current Visual Studio version is now relatively painless. VS2017 to VS2019 took me under half a day from installing to working product build; and most of that time was vcpkg building my third-party dependencies. In contrast, VS2012 to 13 to 15 were rather more onerous undertakings that took weeks to plan and execute. libtiff itself is provided by vcpkg. Takes just a minute to build and be ready to use.

Kind regards,

Roger