Re: git: 25e6f68a6661 - main - textproc/libxml2: Update to 2.11.6
Date: Sat, 13 Jan 2024 10:17:12 UTC
On 2024-01-13T09:02:35.000+01:00, Gleb Popov <arrowd@freebsd.org> wrote: > On Sat, Jan 13, 2024 at 8:14 AM Alexey Dokuchaev <danfe@freebsd.org> wrote: >> Wait, what? You've just removed the comment which tells to NOT >> use the >> >> dreaded CMake and made the switch without logging any rationale? >> CMake >> >> in such low-sitting in dependency tree port is a PITA for many >> people, >> >> please don't push it down our throats as you've been repeatedly >> asked by >> >> other fellow developers. >> >> ./danfe > > I admit that there is no rationale for the switch in the commit > > message. But at the same time, reducing build times for Ports > > consumers has much lower priority for us than actually updating > > software. > > Daniel made sure that the switch doesn't cause circular dependencies > > which was a problem before. Because of that I approved the change, > > just for the sake of the "updating" part. > > Daniel is not being paid for this work, so if he's more comfortable > > with CMake (which I wholeheartedly understand!) it is a sufficient > > rationale for the switch. I believe no one will be against if you > > prepare a patch that will switch back to autotools and do the same > > amount of testing (500+ ports) that Daniel did. > > === > > arrowd with a portmgr-lurker hat on top Hi, I want to add a few things that weren't in the commit message but that's been discussed and mentioned in the bugs report(s) and elsewhere. Local patches are a pain, no one has upstreamed patches for years and there's seemingly little to no interest in doing so. For a single committer that might not be much of an issue but it adds a overall maintenance burden and that specific maintainer/committer will not be around forever. As a community we've reported issues upstream, issues have been fixed and upstreamed patches. This by far a better success story than previously. It isn't perfect but it is in better shape than before and people are willing to contribute. There are more improvments upstream which be in later releases too. While at it lets address the subject about build times in general on a ports tree level. Does CMake/Meson/* add build time looking at a single port? That depends on how you look at it. If you look at a single port for the build itself it's rarely the case. Build times are most of the time reduced by quite a bit or at least on par. XXX pulls in YYY and friends as build dependencies and therefore is "heavy" While that is true compared to "zero" dependenvies I think we can safely assume that most systems are likely to use more than 10 ports or so on a system in general. Given that many projects are or already have migrated to CMake/Meson/* you're very likely to pull these in either way. Looking at the general movement whether you agree or not it's very likely going to be a fruitless effort trying to against it and many projects have trouble maintaining Autotools scripts. Upstream (Autotools) have also mentionend that they're seeing less interest [1] and that seemingly tends to trickle down to project using Autotools. Keep in mind that Autotools isn't free when you need to use USES= autoreconf and/or gmake. CMake/Meson/* usually scale much better on systems utilizing many cores and many "frameworks" also integrates better with build caches such as devel/ccache or devel/sccache if you're looking to further improve build times. Additionally there's very likely an overall gain in the end if we embrace it even without utilizing caches given that builds on single ports bases are in general at least par or faster [1] and maintences/upstream burden. 1: https://lists.gnu.org/archive/html/autoconf/2021-01/msg00049.html 2: https://lists.freebsd.org/archives/freebsd-ports/2023-December/005056.html Best regards, Daniel (diizzy@)