Am 22.03.2025 um 22:12 schrieb Mark Millard:
Just some general notes . . .
Modern upstream thrift seem to be at 0.21.0 . Most of the ports
with fairly modern official builds are at 0.16.0 from what I
saw on freshports. (I ignore "bump consumers" and other such
changes here.)
0.14.0 is when the transition to cmake happened and when the
file installation conflicts of cmake related files started.
That continued with the updates to 0.16.0 .
At least for 0.16.0 , devel/thrift-cpp and devel/thrift-c_glib
have at least/usr/local/include/thrift/config.h also
conflicting.
I make no claim for if the conflicts should be attributed to
upstream issues vs. to how the partitioning into ports was
structured. I've no clue if having a single version of the
compiler (devel/thift) be used across all the devel/*thrift*
language-specific ports would be reasonable or not.
devel/thrift is the thrift system's compiler producing source
for various langauges from thrift source. devel/thrift-cpp and
devel/thrift-c_glib look to be libraries that the "compiled"
C++ vs. C code depends on, for example. The 3 are far from
being independent conceptually as far as I can tell. I've not
looked at the ties for the likes of devel/py-thrift* or
devel/rubygem-thrift or devel/node-thrift or devel/p5-thrift* .
( devel/pear-Horde_Thrift does not seem to have tracking
version numbers and so might not be related. )
I will have a look into this.
I did some investigations and it seems that devel/thrift should be just
the compiler and the cmake files to identify the compiler currectly.
Ports like thrift-cpp are adding support for cpp but they also install
the cmake files of the compiler, which is causing the conflict.
So I think that thrift-cpp should not install files related to the
compiler, but only what needs to be added in addition to support cpp
(same for -c_glib).
I think all thrift-* ports needing some fine-tuning that the files are
nicely separated and that installation of a binding also installs the
compiler as a RUN and maybe build dependency but not files that the
compiler is already providing.
I think I will have next week some time to look into it this issue.
The maintainer [email protected] seems not to answer anymore, maybe
the port should be put back to ports@?
Gruß
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
