pkg-config2

[Zack Rusin]

On Sunday 23 January 2005 00:00, Owen Taylor wrote:
> Can you expand a litle on what features that you want to see added
> and your development plans? The README file there is rather short.

Ah, yes, sorry. Essentially there are two things we would like to see 
addressed:
1) Configuration framework woes. And I know that this is a touchy feely 
subject because people either love or hate autoconf. The reality though 
is that there is quite a few of them out there. pkg-config works quite 
nicely as a system() call from each one of them but it's far from being 
ideal. In qmake I'd love to just say :
DEPENDS += ogg vorbis >= 1.0.1 
Instead of trying to form system() lines that would imitate that. 

2) Remove the need of having tools like kde-config. And again a heated 
discussion because kde-config != pkg-config. The bottom line is that it 
doesn't have to be like that. In the current situation there's no way 
to merge the two. And quite frankly the idea does leverege a lot of the 
need for a common configuration framework for both desktops ("give me a 
directory with wallpapers/bookmarks/services/icons/html 
documentation/mime types"). Like I said, it's only a fraction of it all 
but it's a lot more realistic to expect that to happen a lot sooner 
than a common configuration framework.

And I'm not making any promises or setting deadlines for implementing 
any of the above. The rewrite was initiated to simply make it possible.

And lets consider the negative scenario meaning we don't implement 
anything we were talking about (and to be honest with the amount of 
code I'm working on and the amount of spare time I have, that might be 
very well the case for me, but hopefully not for Ian). Either way 
having a version of pkg-config that does exatly the same thing the 
current version does but is 2 times less lines of code is surely not a 
bad thing, is it?

> Unix at this point. And a library-level API for pkg-config doesn't
> sound interesting enough to me to be worth worrying about whether it
> is C or C++.

With 1 and 2 I listed above I'd completely understand if you would worry 
about that though. But I think that TagLib does  prove that a C++ 
library can easily have nice C bindings . 
(http://developer.kde.org/~wheeler/taglib.html)

Personally, I'm not going to be arguing too hard over this stuff. If 
people think that the plan doesn't make sense and having the 2x bigger 
pkg-config is right on because it works right now I can understand 
that. 

Zack

-- 
I don't tend to think... walking into things is more my style.