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

On 2024-10-10T21:43:21.000+02:00, Kevin Bowling
<kevin.bowling@kev009.com> wrote:

> 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

 One major issue both in our tree and upstream is that very few wants
to hack on autotools scripts and merge/upstream changes (leading to
bitrot and/or ports getting outdated because no one wants to unravel
previous work and so on). We have countless examples of that in tree
already and it keeps eating away precious developer time. 

Even autotools upstream are having issues finding people maintaining
it etc, see
https://lists.gnu.org/archive/html/autoconf/2021-01/msg00049.html .

Speed is another factor that's not in Autotools favour especially if
you also need to use USES= autoreconf, it's slow. We spend a lot of
time processing configure scripts and it's also showing it's age when
it comes to compiling in parallell. There are some projects trying to
improve on this such as slibtool but it's not 100% compatible and no
one is to my knowledge actively looking at it for potential adoption.
Switching from Autotools to lets say CMake or Meson almost always
gives a noticable speed boost and that also includes unit testing. It
may not be a major difference for a single port but it adds up
quickly. It's not the top reason but it's a nice addition.

For this specific port there is also quite a bit more unit tests
connected to CMake build which helps us do regression testing but if
someone(tm) is willing ot get Autotools up to the same level by all
means go ahead and upstream it.

At least 3 deps already requires on CMake and that include libdeflate
so there's nothing "new" in that regard.

With all that being said, I'll try to get around to submit current
patch(es) upstreamed next week or so but they needs a bit of
adjustment before doing so.

Best regards,

Daniel