Date: Sat, 13 Jan 2024 11:17:12 +0100 From: Daniel Engberg <daniel.engberg.lists@pyret.net> To: Gleb Popov <arrowd@freebsd.org> 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: 25e6f68a6661 - main - textproc/libxml2: Update to 2.11.6 Message-ID: <a228d839c5a29d9991b72f1e0664da04@mail.infomaniak.com> In-Reply-To: <CALH631=meexWeEvPY4dBsVviAEms9OfcmKTk-YHGfw4fHJCzSw@mail.gmail.com> References: <202401121705.40CH5JhG014492@gitrepo.freebsd.org> <ZaIcEvYZ2Yq_jW9Z@FreeBSD.org> <CALH631=meexWeEvPY4dBsVviAEms9OfcmKTk-YHGfw4fHJCzSw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--_=_swift_1705141032_55d8067faeef9a6dff31a78e9782a812_=_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2024-01-13T09:02:35.000+01:00, Gleb Popov <arrowd@freebsd.org> wrote:= >=C2=A0On=C2=A0Sat,=C2=A0Jan=C2=A013,=C2=A02024=C2=A0at=C2=A08:14= =E2=80=AFAM=C2=A0Alexey=C2=A0Dokuchaev=C2=A0<danfe@freebsd.org>=C2=A0wrote:= >>=C2=A0=C2=A0Wait,=C2=A0what?=C2=A0You've=C2=A0just=C2=A0removed=C2= =A0the=C2=A0comment=C2=A0which=C2=A0tells=C2=A0to=C2=A0NOT >>=C2=A0=C2= =A0use=C2=A0the >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0dreaded=C2=A0CMake= =C2=A0and=C2=A0made=C2=A0the=C2=A0switch=C2=A0without=C2=A0logging=C2=A0any= =C2=A0rationale? >>=C2=A0=C2=A0CMake >>=C2=A0=C2=A0 >>=C2=A0=C2=A0= =C2=A0in=C2=A0such=C2=A0low-sitting=C2=A0in=C2=A0dependency=C2=A0tree=C2= =A0port=C2=A0is=C2=A0a=C2=A0PITA=C2=A0for=C2=A0many >>=C2=A0=C2=A0people,= >>=C2=A0=C2=A0 >>=C2=A0=C2=A0=C2=A0please=C2=A0don't=C2=A0push=C2= =A0it=C2=A0down=C2=A0our=C2=A0throats=C2=A0as=C2=A0you've=C2=A0been=C2= =A0repeatedly >>=C2=A0=C2=A0asked=C2=A0by >>=C2=A0=C2=A0 >>=C2=A0= =C2=A0=C2=A0other=C2=A0fellow=C2=A0developers. >>=C2=A0=C2=A0 >>=C2= =A0=C2=A0=C2=A0./danfe >=C2=A0 >=C2=A0I=C2=A0admit=C2=A0that=C2=A0there= =C2=A0is=C2=A0no=C2=A0rationale=C2=A0for=C2=A0the=C2=A0switch=C2=A0in=C2= =A0the=C2=A0commit >=C2=A0 >=C2=A0message.=C2=A0But=C2=A0at=C2=A0the= =C2=A0same=C2=A0time,=C2=A0reducing=C2=A0build=C2=A0times=C2=A0for=C2=A0Por= ts >=C2=A0 >=C2=A0consumers=C2=A0has=C2=A0much=C2=A0lower=C2=A0priority= =C2=A0for=C2=A0us=C2=A0than=C2=A0actually=C2=A0updating >=C2=A0 >=C2= =A0software. >=C2=A0 >=C2=A0Daniel=C2=A0made=C2=A0sure=C2=A0that=C2= =A0the=C2=A0switch=C2=A0doesn't=C2=A0cause=C2=A0circular=C2=A0dependencies= >=C2=A0 >=C2=A0which=C2=A0was=C2=A0a=C2=A0problem=C2=A0before.=C2= =A0Because=C2=A0of=C2=A0that=C2=A0I=C2=A0approved=C2=A0the=C2=A0change, >= =C2=A0 >=C2=A0just=C2=A0for=C2=A0the=C2=A0sake=C2=A0of=C2=A0the=C2=A0"upd= ating"=C2=A0part. >=C2=A0 >=C2=A0Daniel=C2=A0is=C2=A0not=C2=A0being= =C2=A0paid=C2=A0for=C2=A0this=C2=A0work,=C2=A0so=C2=A0if=C2=A0he's=C2=A0mor= e=C2=A0comfortable >=C2=A0 >=C2=A0with=C2=A0CMake=C2=A0(which=C2=A0I= =C2=A0wholeheartedly=C2=A0understand!)=C2=A0it=C2=A0is=C2=A0a=C2=A0sufficie= nt >=C2=A0 >=C2=A0rationale=C2=A0for=C2=A0the=C2=A0switch.=C2=A0I=C2= =A0believe=C2=A0no=C2=A0one=C2=A0will=C2=A0be=C2=A0against=C2=A0if=C2=A0you= >=C2=A0 >=C2=A0prepare=C2=A0a=C2=A0patch=C2=A0that=C2=A0will=C2=A0swit= ch=C2=A0back=C2=A0to=C2=A0autotools=C2=A0and=C2=A0do=C2=A0the=C2=A0same >= =C2=A0 >=C2=A0amount=C2=A0of=C2=A0testing=C2=A0(500+=C2=A0ports)=C2=A0tha= t=C2=A0Daniel=C2=A0did. >=C2=A0 >=C2=A0=3D=3D=3D >=C2=A0 >=C2=A0arr= owd=C2=A0with=C2=A0a=C2=A0portmgr-lurker=C2=A0hat=C2=A0on=C2=A0top Hi,= I want to add a few things that weren't in the commit message but t= hat'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 comm= itter that might not be much of an issue but it adds a overall maintenanc= e burden and that specific maintainer/committer will not be around foreve= r. As a community we've reported issues upstream, issues have been fixed = and upstreamed patches. This by far a better success story than previousl= y. 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 la= ter releases too. While at it lets address the subject about build tim= es in general on a ports tree level. Does CMake/Meson/* add build ti= me looking at a single port? That depends on how you look at it. If yo= u 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 "h= eavy" While that is true compared to "zero" dependenvies I think we ca= n 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 hav= e migrated to CMake/Meson/* you're very likely to pull these in either wa= y. Looking at the general movement whether you agree or not it's very lik= ely going to be a fruitless effort trying to against it and many projects= have trouble maintaining Autotools scripts. Upstream (Autotools) have al= so mentionend that they're seeing less interest [1] and that seemingly te= nds to trickle down to project using Autotools. Keep in mind that Autotoo= ls isn't free when you need to use USES=3D autoreconf and/or gmake. CMake= /Meson/* usually scale much better on systems utilizing many cores and ma= ny "frameworks" also integrates better with build caches such as devel/cc= ache or devel/sccache if you're looking to further improve build times. A= dditionally 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/0= 05056.html Best regards, Daniel (diizzy@) --_=_swift_1705141032_55d8067faeef9a6dff31a78e9782a812_=_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <div>On 2024-01-13T09:02:35.000+01:00, Gleb Popov <arrowd@freebsd.org>= ; wrote:<br></div><div class=3D"ik_mail_quote answerContentMessage"><blockq= uote class=3D"ws-ng-quote"><pre style=3D"white-space: normal;"><div>On Sat,= Jan 13, 2024 at 8:14=E2=80=AFAM Alexey Dokuchaev <<a href=3D"mailto:dan= fe@freebsd.org" class=3D"defaultMailLink">danfe@freebsd.org</a>> wrote:<= br></div><blockquote class=3D"ws-ng-quote"><div> <br></div><div><br></div><= div> Wait, what? You've just removed the comment which tells to NOT use th= e<br></div><div> dreaded CMake and made the switch without logging any rati= onale? CMake<br></div><div> in such low-sitting in dependency tree port is= a PITA for many people,<br></div><div> please don't push it down our throa= ts as you've been repeatedly asked by<br></div><div> other fellow developer= s.<br></div><div><br></div><div> ./danfe<br></div></blockquote><div> <br></= div><div>I admit that there is no rationale for the switch in the commit<br= ></div><div>message. But at the same time, reducing build times for Ports<b= r></div><div>consumers has much lower priority for us than actually updatin= g<br></div><div>software.<br></div><div>Daniel made sure that the switch do= esn't cause circular dependencies<br></div><div>which was a problem before.= Because of that I approved the change,<br></div><div>just for the sake of = the "updating" part.<br></div><div><br></div><div>Daniel is not being paid = for this work, so if he's more comfortable<br></div><div>with CMake (which = I wholeheartedly understand!) it is a sufficient<br></div><div>rationale fo= r the switch. I believe no one will be against if you<br></div><div>prepar= e a patch that will switch back to autotools and do the same<br></div><div>= amount of testing (500+ ports) that Daniel did.<br></div><div><br></div><di= v>=3D=3D=3D<br></div><div>arrowd with a portmgr-lurker hat on top<br></div>= </pre></blockquote></div><div>Hi,<br></div><div><br></div><div>I want to ad= d a few things that weren't in the commit message but that's been discussed= and mentioned in the bugs report(s) and elsewhere.<br></div><div><br></div= ><div>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 committe= r that might not be much of an issue but it adds a overall maintenance burd= en and that specific maintainer/committer will not be around forever. As a = community we've reported issues upstream, issues have been fixed and upstre= amed 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 con= tribute. There are more improvments upstream which be in later releases too= .<br></div><div><br></div><div>While at it lets address the subject about b= uild times in general on a ports tree level.<br></div><div><br></div><div>D= oes CMake/Meson/* add build time looking at a single port?<br></div><div>Th= at depends on how you look at it. If you look at a single port for the buil= d itself it's rarely the case. Build times are most of the time reduced by = quite a bit or at least on par.<br></div><div><br></div><div>XXX pulls in Y= YY and friends as build dependencies and therefore is "heavy"<br></div><div= >While that is true compared to "zero" dependenvies I think we can safely a= ssume that most systems are likely to use more than 10 ports or so on a sys= tem in general. Given that many projects are or already have migrated to CM= ake/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 fr= uitless effort trying to against it and many projects have trouble maintain= ing Autotools scripts. Upstream (Autotools) have also mentionend that they'= re seeing less interest [1] and that seemingly tends to trickle down to pro= ject using Autotools. Keep in mind that Autotools isn't free when you need = to use USES=3D autoreconf and/or gmake. CMake/Meson/* usually scale much be= tter on systems utilizing many cores and many "frameworks" also integrates = better with build caches such as devel/ccache or devel/sccache if you're lo= oking to further improve build times. Additionally there's very likely an o= verall 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.<br></div><div><br></div><div>1: <a href= =3D"https://lists.gnu.org/archive/html/autoconf/2021-01/msg00049.html">http= s://lists.gnu.org/archive/html/autoconf/2021-01/msg00049.html</a><br></div>= <div>2: <a href=3D"https://lists.freebsd.org/archives/freebsd-ports/2023-De= cember/005056.html">https://lists.freebsd.org/archives/freebsd-ports/2023-D= ecember/005056.html</a><br></div><div><br></div><div>Best regards,<br></div= ><div>Daniel (diizzy@)<br></div> --_=_swift_1705141032_55d8067faeef9a6dff31a78e9782a812_=_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a228d839c5a29d9991b72f1e0664da04>