On 4.2.2006, at 20:35, joerg%britannica.bec.de@localhost wrote:
No, the point of pkg(-)config is to workaround the brain-damaged mess created in hundred tousand autoconf scripts. But that's a different issue.
Someone else who intensely dislikes autoconf. Good. What a horrible hack to cover incompetence, the entire autoconf system. It would have been so much simpler just to require a well-known make tool; now we have even worse requirements, and the mess. *sigh*
The real problem is that the builtin.mk support now has to deal with either copying or linking the native .pc files if available. This is further complicated by its possible omission on some platforms. Justpushing /usr/lib/pkgconfig or wherever they are for native pkgconfig is*not* an option, since that would remove all the protection against overaggressive configure scripts buildlink3 offers.
Actually, I just figured out a "fit-for-a-FAQ" solution to the problem. Add this to mk.conf, and the mechanism works just like I'd expect it to:
_PKG_CONFIG_LIBDIR=${PKG_CONFIG_PATH}
If the native versions have .pc files installed in PKG_CONFIG_PATH,
they will be found; if not, then it's up to the configure script to
figure out (with or without buildlink3's help) if the component is
available. If the user (in this case me) is brave enough to
USE_BUILTIN in the first place, s/he'd better know what .pc files
there are present, and how to set PKG_CONFIG_PATH properly.
The poor box hasn't had time to rebuild everything yet with this in place, but so far so good, shared-mime-info just built OK. Unless there are unexpected side-effects, I'm happy with this solution.