Date: Fri, 01 Apr 2022 08:34:57 +0000 From: bugzilla-noreply@freebsd.org To: desktop@FreeBSD.org Subject: [Bug 262853] textproc/libxslt and textproc/libxml2: circular dependencies when using CMake Message-ID: <bug-262853-39348-PvVCYd82i7@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262853-39348@https.bugs.freebsd.org/bugzilla/> References: <bug-262853-39348@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262853 --- Comment #17 from Daniel Engberg <diizzy@FreeBSD.org> --- (In reply to Tijl Coosemans from comment #16) Agreed, it's always tricky and there are a few issues to consider overall. While it might be a combination of interest, time and funds (its been menti= oned that the project pretty much recieves no funding) or something else upstream struggles with Autotools and very few induviduals in general wants to touch= it. As a consequence of this we as well as other distros do various hacks to wo= rk around these issues using packaging frameworks without upstreaming because= no one wants to touch it more or less and simply because they're not upstreama= ble. That leads us down the road of the maintenance, in that regard I think we c= an all agree upon that any form of patching and/or hacking by hand indirectly discourages people to work on X. Simply because it requires additional investment trying to figure what XYZ does and what it tries to fix/fixes. In that regard we do have people, there is general interest in fixing issues a= nd upstream is willing to accept patches (https://gitlab.gnome.org/GNOME/libxml2/-/issues/360#note_1418502). If I we= re to speculate about upstreams current standpoint I'd guess that they're aware that libxml2 is used on various less common platforms which CMake (in this case) doesn't support and/or dropped support for a long time ago and simply don't want to take that discussion. Since several have contributed and without any vocal objections I'd assume = that they're in agreement rather than disagreement. I fully agree that fallouts never are favourable and should be avoided if possible. That being said, I = also think that it may sometimes be necessary to move forward within reasonable tradeoffs. Regarding dependencies it's always hard to do a good assessment simply beca= use there's no way of telling. I do however think that while we do see projects migrating from Autotools to mainly CMake and Meson it's fair to say that mo= st dependencies are "fortunately" stuck with Autotools due to legacy compatibi= lity and/or to simply avoid circular dependency. In case of a switch I think we'= re more likely to see a switch to Meson rather than CMake to avoid circular dependency and due to the fact that CMake and/or Meson are a lot less painf= ul to use on Windows platforms than Autotools which many dependencies also targets. Best regards, Daniel --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262853-39348-PvVCYd82i7>