On 07/09/2024 00:12, Even Rouault via Tiff wrote:
Le 07/09/2024 à 01:05, Bob Friesenhahn a écrit :
I do have the autoconf-archive M4 macros installed. The change for
AX_CHECK_GL was put into a merge request for the release, and that
seems risky to me. It should be merged into head separately in
advance, with perhaps a day for others to verify that they can
reproduce the build.
Dependence on autoconf-archive M4 macros is risky because not all
systems will have the same version. It is worth encouraging testing
to make sure that it works with the autoconf-archive provided by
various major OS versions.
The only way to assure that the macros are the desired latest release
version is to retrieve them from gnu.org (which was down for a day or
two in this past week).
hum, ok if that's thought to be controversial / risky, I'm leaning to
reverting this merge request and let other people deal with the issues
it tried to solve. I don't care about autoconf builds when I've the
chance to be able to use CMake instead (if that was just me, I would
get rid of autoconf support from libtiff to only keep the CMake one,
and just maintain one single build system, but that's a battle for
another time), and I don't want to be bothered with autoconf related
issues and having to do several RCs due to that.
I would prefer it if we could drop the autotools at this point and
simply use CMake.
There is a significant maintenance burden to maintaining two systems in
parallel, and we pay for that in both maintainer time and in the CI, and
in the lost opportunity to make changes. We have to ensure that both
systems behave identically, and this is both harder than maintaining
either system in isolation and it means that CMake has had to be
completely behaviour compatible with the historical autotools behaviour
even when it was suboptimal.
There are quite a few things I'd like to do to improve libTIFF, for
example much better and more comprehensive testing, which I've put off
pretty much because writing all of the build tools test logic twice over
would be prohibitive. Everything we want to do that touches the build
needs doing twice over, including all of the testing to ensure both are
identical. It's too much, and it is preventing us doing new work that
would be of value.
I was an Autoconf user and occasional contributor for many years, but
I'm afraid the world moved on, and it's thoroughly obsolete and barely
maintained. It's past time to let it go. It went for 8 years without a
release, and there were three releases the past few years but it's
stagnated to the point no real changes can be made because of the
architectural decisions made decades prior. See
https://ftp.gnu.org/gnu/autoconf/ for the release dates, and have a look
at the mailing list. Compare that with the sustained and ongoing
activity around CMake [https://github.com/Kitware/CMake/tags] where
there are point releases for multiple stable branches coming out at
least monthly. It's actively maintained and solves the portability
problems we have on *all* contemporary platforms, including Windows,
Android and the rest. It's comprehensive and supports absolutely
everything. I would really prefer for us to put our effort into the
build system which has the most value, and that system cannot be
Autoconf because of its inherent restriction to shell/make. Switching
to CMake will not disadvantage any of our users, since it works
perfectly well on all of the platforms Autoconf supports, and it can
generate Makefiles perfectly well.
Kind regards,
Roger
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
