Re: git: 0bdf5887f0d2 - main - graphics/tiff: Update to 4.7.0 and switch to CMake

On Thu, Oct 10, 2024 at 8:55 AM Alexey Dokuchaev <danfe@freebsd.org> wrote:
>
> On Wed, Oct 09, 2024 at 02:28:01PM -0700, Kevin Bowling wrote:
> > On Wed, Oct 9, 2024 at 12:43???PM Daniel Engberg <diizzy@freebsd.org> wrote:
> > >
> > > The branch main has been updated by diizzy:
> > >
> > > URL: https://cgit.FreeBSD.org/ports/commit/?id=0bdf5887f0d2cc9f14ea0cc10ed9e371028dd620
> > >
> > > commit 0bdf5887f0d2cc9f14ea0cc10ed9e371028dd620
> > > Author:     Daniel Engberg <diizzy@FreeBSD.org>
> > > AuthorDate: 2024-10-09 19:12:09 +0000
> > > Commit:     Daniel Engberg <diizzy@FreeBSD.org>
> > > CommitDate: 2024-10-09 19:43:25 +0000
> > >
> > >     graphics/tiff: Update to 4.7.0 and switch to CMake
> >
> > I believe this might have come up in the past but I do not remember
> > any conclusion.
> >
> > Upon a quick look at Debian and Fedora (thus accounting for the
> > majority of all *nix builds/usage) I do not see either using CMake:
> > * https://sources.debian.org/src/tiff/4.6.0-2/debian/rules/#L16
> > * https://src.fedoraproject.org/rpms/libtiff/blob/rawhide/f/libtiff.spec#_68
>
> +1 to reverting back to GNU autotools which entail far less dependencies.
> I've lost count already when I have to revert Daniel's CMake switches in
> various ports to unbreak them in my environments.  It was common to half-
> jokingly wish autotools to die, but they remain stable, working, and not
> asking too much, thus being clear winner among other build options.

From a maintainer/developer's view, Autoconf is an arcane mix of
shell, M4 so the hate is understandable.  From a packager's view it is
nearly ideal for historical interial reasons and one key point:  the
thing that Autoconf gets right is being centered around feature test
macros and most alternative build systems miss that point and center
around preconceived notions of what a platform is or has.  Ted Tso (of
ext2 fame) wrote a nice piece about this on TUHS recently.  This, for
instance, makes it easy to taste APIs and accommodate i.e. MFCs back
to arbitrary FreeBSD versions without a fragile maintenance of
checking specific __FreeBSD_version or whatever the case may be.  It
also lends to putting arbitrary portability in the source code instead
of the build system.

> In other words, don't pull CMake when you can pull nothing (/bin/sh and
> friends are part of the base system).

I think one of the previous justifications for this toil was speed
which seems dubious because now a very light library like libtiff will
have to wait around for a high cardinality C++ project to build.

All of this doesn't really matter if CMake is the clear choice of
upstream.  But that is not the case here.

> ./danfe