pkg-config2

[Ian Reinhart Geiser]

On Saturday 22 January 2005 20:20, Daniel Stone wrote:
> On Sat, Jan 22, 2005 at 06:49:40PM -0500, Ian Reinhart Geiser wrote:
> > Pkg-conf is one of the most promising tools that I have seen in a while. 
> > It makes a great attempt at solving interdependencies of development
> > packages. The only gripes I have had with it so far have been its lack of
> > formal documentation, and the current implementation seems to lack real
> > development effort behind it.
>
> Not being funny or anything, but what development is there really to do? 
> Some stuff is stagnant just because there isn't really anything to do, bar
> cleaning up an M4 warning.
>
Well currently there is duplication in applications like kde-config and there 
is lack of support in applications like QMake.  This development is 
specificly to address these issues.  The current implementation while it 
provides a nice base seems very difficult to extend.  This development also 
addresses this issue but sporting a slightly more manageable codebase along 
with tests to ensure maintainability.

> > Zack Rusin and I have built a completely testdriven version in C++ and
> > have started on using those tests to build formal documentation of the
> > format.  We have also started to build an API so that applications such
> > at kde-config and other binary *-conf utilities can reuse pkg-conf
> > metadata, dependencies and features without having to re-invent the wheel
> > every time.
>
> Personally, I would've thought it would be far better to just use
> pkg-config directly (y'know you can get arbitrary variables out of it,
> yeah?), and be done with *-conf, forever, and just do everything through
> the one standard interface.
>
Sure, and this is neat for static data.  This fails pretty miserably though 
with dynamic data like kde standard directories that are influenced by KDE 
settings.  The goal is to allow such tools to use the current featureset of 
PkgConf and then extend it at their own requirements.

> > Interested parties should kick it around and suggest patches.  We are
> > still working on Win32 support.  It build right now with mingw32, but the
> > paths are still not correct.  This is alpha and should be updated later
> > this week.
>
> I'm honestly not entirely convinced I see the point:
> 	a) why have you rewritten it?
The code as it stood was not really maintained and very difficult to extend 
and integrate
> 	b) why have you decided to encourage applications to use their own
> 	   frontends,  other than going through pkg-config itself? 
Because forcing applications to duplicate 99% of the functions of pkg-conf 
just because it cannot be extended to provide their required features is not 
a useful way to promote adoption of the .pc format.  This is a big reason why 
kde has their kde-config vs using pkg-conf... The net result is we duplicate 
pkg-conf poorly, and have redundant code.

> 	c) does this version carry any other advantages over the main one?
It will provide documentation of the format. Validation tests to provide devs 
with a way to definitively prove their .pc file is valid.  It will also 
provide an interface to allow build tools like scons, and QMake integrate 
better. 	
> 	d) what are your plans for future development, so it never stagnates?
Without falling back on the argument of Test Driven code is easier to 
maintain, I think the biggest plans are to take a more active role in getting 
this integrated into build systems and to get features that developers want 
into it.  My biggest current gripe is to be able to have environment 
variables to be usable inside of the .pc format.  This is handy when you have 
multiple installs of certain libraries and do not wish to manually update the 
pc files or hack on the build system.

Example:
pc file contains %{prefix} before its libs... this is defined either via a 
cmdline option or prior in the .pc file.  Modifying this within automake is 
difficult.  With env variable support one could set their $PREFIX or 
something and then build with autotools as usual.  Currently you cannot have 
more than one of a module type in packageconf. This make keeping multiple 
copies difficult and requires dorking with the pkgconf path.

> Daniel, quite possibly missing the point
No your questions are good.  I assure you I did not do this out of boredom. I 
did this because I believe the intent of Pkg-Conf is spot on, but I think 
some of the points of the implementation needed refinement.  I think pkgconf 
is here to stay one way or another, I just see this implementation as helping 
make it more popular.  The .pc format is the standard interface imho, the 
implementations can vary as we please.

Cheers
	-ian reinhart geiser
-- 
=======+<KWeather for KDE 3.2>+=+<http://www.kde.org>+===
 Report for Philadelphia, Northeast Philadelphia Airport
            on Saturday 22 January 2005 20:54
 -6.7°C with winds at 20 km/h NNW and 8km of visibility.
===============================+<geiseri at kde.org>+=======
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050122/468ded3b/attachment.pgp