Date: Thu, 10 Oct 2024 22:40:09 +0200 From: Daniel Engberg <daniel.engberg.lists@pyret.net> To: Kevin Bowling <kevin.bowling@kev009.com> Cc: Alexey Dokuchaev <danfe@freebsd.org>, Daniel Engberg <diizzy@freebsd.org>, ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: 0bdf5887f0d2 - main - graphics/tiff: Update to 4.7.0 and switch to CMake Message-ID: <0367156086892980fb78cc6aacdba56f@mail.infomaniak.com> In-Reply-To: <CAK7dMtAr4Le6JA_VPGXb-aLUiBkTRLP3BpYJC=O40Sc1Sjn-5Q@mail.gmail.com> References: <202410091943.499JhXKg087859@gitrepo.freebsd.org> <CAK7dMtBHq5kbQU4DXW%2B7xOLHYo%2BVRa%2B0h=ra0b-_xW3gvGsXWg@mail.gmail.com> <Zwf459b9bCrpegd1@FreeBSD.org> <CAK7dMtAr4Le6JA_VPGXb-aLUiBkTRLP3BpYJC=O40Sc1Sjn-5Q@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] <html><body><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px">On 2024-10-10T21:43:21.000+02:00, Kevin Bowling <kevin.bowling@kev009.com> wrote:<br></div><div ><div><br></div></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px"><br></div><div class="ik_mail_quote answerContentMessage"><blockquote class="ws-ng-quote"><pre style="white-space: normal;"><div>On Thu, Oct 10, 2024 at 8:55 AM Alexey Dokuchaev <<a href="mailto:danfe@freebsd.org" class="defaultMailLink">danfe@freebsd.org</a>> wrote:<br></div><blockquote class="ws-ng-quote"><div> <br></div><div> On Wed, Oct 09, 2024 at 02:28:01PM -0700, Kevin Bowling wrote:<br></div><blockquote class="ws-ng-quote"><div> On Wed, Oct 9, 2024 at 12:43???PM Daniel Engberg <<a href="mailto:diizzy@freebsd.org" class="defaultMailLink">diizzy@freebsd.org</a>> wrote:<br></div><blockquote class="ws-ng-quote"><div> <br></div><div> The branch main has been updated by diizzy:<br></div><div> <br></div><div> URL: <a href="https://cgit.FreeBSD.org/ports/commit/?id=0bdf5887f0d2cc9f14ea0cc10ed9e371028dd620" class="defaultMailLink" rel="noopener noreferrer" data-ik="ik-secure" target="_blank">https://cgit.FreeBSD.org/ports/commit/?id=0bdf5887f0d2cc9f14ea0cc10ed9e371028dd620</a><br></div><div>; <br></div><div> commit 0bdf5887f0d2cc9f14ea0cc10ed9e371028dd620<br></div><div> Author: Daniel Engberg <<a href="mailto:diizzy@FreeBSD.org" class="defaultMailLink">diizzy@FreeBSD.org</a>><br></div><div> AuthorDate: 2024-10-09 19:12:09 +0000<br></div><div> Commit: Daniel Engberg <<a href="mailto:diizzy@FreeBSD.org" class="defaultMailLink">diizzy@FreeBSD.org</a>><br></div><div> CommitDate: 2024-10-09 19:43:25 +0000<br></div><div> <br></div><div> graphics/tiff: Update to 4.7.0 and switch to CMake<br></div></blockquote><div> <br></div><div> I believe this might have come up in the past but I do not remember<br></div><div> any conclusion.<br></div><div> <br></div><div> Upon a quick look at Debian and Fedora (thus accounting for the<br></div><div> majority of all *nix builds/usage) I do not see either using CMake:<br></div><div> * <a href="https://sources.debian.org/src/tiff/4.6.0-2/debian/rules/#L16" class="defaultMailLink" rel="noopener noreferrer" data-ik="ik-secure" target="_blank">https://sources.debian.org/src/tiff/4.6.0-2/debian/rules/#L16</a><br></div><div>; * <a href="https://src.fedoraproject.org/rpms/libtiff/blob/rawhide/f/libtiff.spec#_68" class="defaultMailLink" rel="noopener noreferrer" data-ik="ik-secure" target="_blank">https://src.fedoraproject.org/rpms/libtiff/blob/rawhide/f/libtiff.spec#_68</a><br></div></blockquote><div>; <br></div><div> +1 to reverting back to GNU autotools which entail far less dependencies.<br></div><div> I've lost count already when I have to revert Daniel's CMake switches in<br></div><div> various ports to unbreak them in my environments. It was common to half-<br></div><div> jokingly wish autotools to die, but they remain stable, working, and not<br></div><div> asking too much, thus being clear winner among other build options.<br></div></blockquote><div> <br></div><div>From a maintainer/developer's view, Autoconf is an arcane mix of<br></div><div>shell, M4 so the hate is understandable. From a packager's view it is<br></div><div>nearly ideal for historical interial reasons and one key point: the<br></div><div>thing that Autoconf gets right is being centered around feature test<br></div><div>macros and most alternative build systems miss that point and center<br></div><div>around preconceived notions of what a platform is or has. Ted Tso (of<br></div><div>ext2 fame) wrote a nice piece about this on TUHS recently. This, for<br></div><div>instance, makes it easy to taste APIs and accommodate i.e. MFCs back<br></div><div>to arbitrary FreeBSD versions without a fragile maintenance of<br></div><div>checking specific __FreeBSD_version or whatever the case may be. It<br></div><div>also lends to putting arbitrary portability in the source code instead<br></div><div>of the build system.<br></div><div><br></div><blockquote class="ws-ng-quote"><div> In other words, don't pull CMake when you can pull nothing (/bin/sh and<br></div><div> friends are part of the base system).<br></div></blockquote><div> <br></div><div>I think one of the previous justifications for this toil was speed<br></div><div>which seems dubious because now a very light library like libtiff will<br></div><div>have to wait around for a high cardinality C++ project to build.<br></div><div><br></div><div>All of this doesn't really matter if CMake is the clear choice of<br></div><div>upstream. But that is not the case here.<br></div><div><br></div><blockquote class="ws-ng-quote"> ./danfe<br></blockquote></pre></blockquote></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px"><br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px"> 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. <br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px"><br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px">Even autotools upstream are having issues finding people maintaining it etc, see <a data-ik="ik-secure" rel="noopener noreferrer" href="https://lists.gnu.org/archive/html/autoconf/2021-01/msg00049.html" target="_blank">https://lists.gnu.org/archive/html/autoconf/2021-01/msg00049.html</a>; .<br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px"><br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px">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.<br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px"><br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px">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.<br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px"><br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px">At least 3 deps already requires on CMake and that include libdeflate so there's nothing "new" in that regard.<br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px"><br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px">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.<br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px"><br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px">Best regards,<br></div><div style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px">Daniel<br></div></body></html>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0367156086892980fb78cc6aacdba56f>