As you may have seen, I have replaced the remaining uses of the libiconv module with plain library dependencies and removed the module. I'm now looking at making further dents into the use of the gettext module.
Our rules for when to use LIB_DEPENDS and when to just list a library in WANTLIB are already vague. These modules (originally introduced to support static archs!) make it all worse by specifying too many dependencies and now when we want to remove the module, we don't know what's actually needed by the port. For iconv, I went ahead and did basically this: -MODULES += converters/libiconv +LIB_DEPENDS += converters/libiconv +WANTLIB += iconv That's already a bit questionable since many of those ports may not use iconv directly and only pull it in by way of a dependency, so the WANTLIB entry would be sufficient. But the above doesn't require a REVISION bump and individually deciding this for hundreds of ports is just not feasible. For gettext, the equivalent would be: -MODULES += devel/gettext +LIB_DEPENDS += converters/libiconv devel/gettext +WANTLIB += iconv intl If we created a new port, we would hardly use this. We'd just say LIB_DEPENDS += devel/gettext and WANTLIB += iconv intl, or quite possibly only have WANTLIB if gettext is only used indirectly. But again, this would require individual decisions and REVISION bumps. Sigh. Maybe I'm overthinking this. Having extra LIB_DEPENDS doesn't actually hurt. PS: The above only applies to simple ports. These modules also add RUN_DEPENDS. For simple ports, that coalesces with the LIB_DEPENDS. But if you have MULTI_PACKAGES, chances are some subpackages picked up extraneous dependencies, and when these go away, a REVISION bump is needed.) And let's not forget, some gettext users also require a BUILD_DEPENDS += devel/gettext-tools. -- Christian "naddy" Weisgerber na...@mips.inka.de
