On 4.2.2006, at 20:35, joerg@britannica.bec.de 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. Just
>  pushing /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.