[Bug 262853] textproc/libxslt and textproc/libxml2: circular dependencies when using CMake

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262853

--- 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 mentioned
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 work
around  these issues using packaging frameworks without upstreaming because no
one wants to touch it more or less and simply because they're not upstreamable.

That leads us down the road of the maintenance, in that regard I think we can
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 and
upstream is willing to accept patches
(https://gitlab.gnome.org/GNOME/libxml2/-/issues/360#note_1418502). If I were
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 because
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 most
dependencies are "fortunately" stuck with Autotools due to legacy compatibility
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 painful
to use on Windows platforms than Autotools which many dependencies also
targets.

Best regards,
Daniel

-- 
You are receiving this mail because:
You are the assignee for the bug.