2021.01.04 14:23 "[Tiff] Motions related to C99 use in libtiff", by Even Rouault

2021.01.04 19:00 "Re: [Tiff] Motions related to C99 use in libtiff", by Even Rouault

Motion 1:

Require compiler with C99 support to build libtiff

Motion 2 (requires Motion 1 to pass):

Allow use of C99 data types in libtiff API instead of custom [u]intXXX typedefs, thus requiring code using libtiff to have C99 build capabilities (will cause a API and ABI breakage)

Candidate implementation for both by Roger Leigh at:
        https://gitlab.com/rleigh/libtiff/-/commits/require-c99

I am also +1 on both in concept.

As a packager, I would like to see a transition period where there is a tiff release that supports the new API, and also the old API. Then, after packages that depend on tiff are updated, or we decide they aren't going to, the old API can be withdrawn.

I don't much care about ABI, as in the packaging world having to rebuild things is not a big deal. What is a big deal is not being able to build things because they use the old API still, but the old API is gone. This is extra tricky when there are packages that people care about but which do not have active maintenance. Even knows how difficult this has been for proj.

Yes, but for PROJ, we completely changed API. Here we are discussing about changing "uint32" to "uint32_t" in code. Shouldn't be a big deal...

There's a momentum currently thanks to Roger to do those changes. I'm afraid having to deal with a multi-year transition of API will loose that momentum. If there's an easily way to use the old API, people will use it and defer the move to the new API until the old API is completely removed. So you're just loosing time.

Spatialys - Geospatial professional services
http://www.spatialys.com