Am Wed, 20 Nov 2024 13:55:23 +0100 schrieb Thomas Klausner <wiz%gatalith.at@localhost>: > Requires.private means that the main library uses the other library's > interface in a hidden way, as a kind of implementation detail, but > users of the main library don't need to know and don't need to link > against the other library (except, I think, when linking statically). > > buildlink3.mk must include the buildlink3.mk files for the first > type, but not the second. OK. So maybe Jonathan's pain level can be reduced by revising buildlink files to better follow that rule. A quick find + grep shows these packages bringing in icu: ./x11/qt6-qtbase/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./x11/qt5-qtbase/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./mail/evolution-data-server/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./time/libical/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./devel/gnustep-base/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./lang/mozjs78/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./lang/mono/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./lang/parrot/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./lang/nodejs20/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./lang/nodejs18/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./lang/nodejs/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./lang/nodejs22/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./math/qalculate/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./graphics/vtk/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./sysutils/gnome-tracker/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./databases/mongo-c-driver/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./databases/sqlite3/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./misc/sword/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./converters/libcdr/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./converters/libmspub/buildlink3.mk:#.include "../../textproc/icu/buildlink3.mk" ./converters/libvisio/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./net/yaz/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./textproc/libxml2/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./textproc/hfstospell/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./www/webkit-gtk/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./games/liblcf/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/mono/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/webkit-gtk4/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/mono-git/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/xalan-c-1.10/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/hs-uconv/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/xalan-c/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/webkit-gtk/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/qt5-qtbase-git/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/spidermonkey31/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/hs-text-icu/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" ./wip/coreclr-git/buildlink3.mk:.include "../../textproc/icu/buildlink3.mk" I see 37 buildlink files pulling in icu. Looking at Makefile*|options.mk files that include icu's buildlink, I count 135 uses, of which 25 do have a buildlink3.mk that does _not_ pull in icu, while 35 do have it (maybe that is a counting error in my rough approach). So of the packages that do rely on icu, a relative majority does treat it as a Requires.private, but a large minority does treat it as a Requires. I suspect hat this majority of Requires.private type could be smaller. I'll pick one possibly influential example: libxml2. It pulls in icu in its buildlink3.mk and options.mk, depending on icu being chosen. Now … I don't see how libxml2 does pull in icu API. Its headers don't seem to include any icu header (grep unicode/ on its headers results in nothing). There's xmlunicode.h which might depend on the build being done with or without icu, but I don't see an indication that it changes with icu versions. (a strange header with lanaguage names hardcoded in function symbols … seems wasteful … perhaps like icu) Dropping icu from libxml2's buildlink3.mk could reduce the revbumping, I suppose. For a perspective: On my Source Mage system, even without libxml2 being built with icu (didn't miss it so far …), I got 933 packages installed. Of these, 12 depend on icu directly. Indirectly, 663 depend on it. An ICU update is annoying, but it is far from a full system rebuild. Alrighty then, Thomas -- Dr. Thomas Orgis Universität Hamburg Regionales Rechenzentrum / Regional Computing Center Basis-Infrastruktur / Basic Infrastructure High-Performance Computing Schlüterstr. 70 20146 Hamburg Tel.: +49 40 42838 8826 E-Mail: thomas.orgis%uni-hamburg.de@localhost Team: hpc%uni-hamburg.de@localhost https://www.uni-hamburg.de https://www.rrz.uni-hamburg.de
Attachment:
smime.p7s
Description: S/MIME cryptographic signature