pkg-config2

[Daniel Stone]

On Sat, Jan 22, 2005 at 09:59:11PM -0500, Ian Reinhart Geiser wrote:
> On Saturday 22 January 2005 20:20, Daniel Stone wrote:
> > 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

I strongly believe that kde-config should not exist, and that it should be a
function of pkg-config.

> and there 
> is lack of support in applications like QMake.

... surely there are easier ways to go about this than rewriting it.  (QMake
isn't exactly a modicum of modernity, BTW.)

> 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.

'Manageable' is a bit handwavey, but the tests are a good idea.  Again, though,
surely the tests could've been done within the same codebase?

> > 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.

Your dynamic data comment is interesting, but again, couldn't this be done
within the current codebase?

When you use other frontends, you lose all the consistency that pkg-config
provides.  Right now, let's say I want KDE.  I would expect that, if KDE was
using pkg-config, then I would be able to run PKG_CHECK_MODULES(FOO, kde), or
such, and reasonably expect it to work.  Or pkg-config --cflags kdefx.  Or
whatever.

If you want *-conf, seriously, don't use pkg-config.  Just keep using your own
stuff.  But that's a horror, and we've been down that path already with
FreeType, GTK+, et al, and that was almost exactly the reason why pkg-config was
written in the first place.  So I can understand the reluctance to provide for
unnecessary fragmentation again.

> > > 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

How do you know it was 'not really maintained'?  Did it have many outstanding
bugs that Scott failed to fix because he's lazy?  Have you followed up on these
bugs?  Offered assistance?

> > 	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.

Again, I think that sure there's a fundamental problem here, but I'll give you a
hint: it's not pkg-config.  It's *-conf, and the existance thereof.

It would be nice if pkg-config was extensible with Python or some other
embeddable language to provide this sort of thing (dynamicity of answers), but
honestly, other frontends really aren't the solution to this.  If you're going
to have multiple frontends, then *.pc is utterly pointless, because you're still
dependent on your frontend.

Imagine if *.desktop files written for KDE were absolutely useless in GNOME, and
vice-versa.  Now ponder the usefulness of the .desktop standard in this scenario.

> > 	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. 	

How will qmake 'integrate better'?  If what you're saying is true, and this is
how you carry it out, then kdelibs (e.g.) will ship kdefx.pc, kdeui.pc,
kdecore.pc, and whatever.  But pkg-config won't be able to usefully read them,
and the answers it gives if it tries will be either useless (something like
::KDE_BASE_DIR::/share/applications, or whatever), or misleading (not what
kde-conf would give you).  And at that point, you've taken a step backwards,
because you have a nice little façade of compatibility and standards, but what
you have in reality is still hopelessly fragmented.

Put it this way: if I want to use KDE, I still have to use some other random
frontend.  I can't use pkg-config.

At this point, pkg-config provides no advantage to me, because I still have to
have your tools installed to make use of the file, and the standard tool won't
have anything to do with the file.  All you're doing is changing the sort of
non-standard file format you're using; you are not (repeat, not) creating a new,
useful, standard.

> > 	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.

Err ... how is $PKG_CONFIG_PATH not the best thing to do here?  If I have
multiple installs of something (let's say -- Qt), it's probably because they're
different, which would presumably include me being required to compile with
different CFLAGS, prefixes, etc.  If I have one in /usr, and one in /opt/qt3,
their directory layout within that will probably be quite radically different --
taking the settings from my /usr install and applying them to /opt/qt3 by only
changing $PREFIX would leave me with a broken inconsistent install.  Surely the
way to solve this problem is just to contain everything you need within .pc
files, and when you want to build something for the /opt/qt3 install, run with
PKG_CONFIG_PATH=/opt/qt3/lib/pkgconfig:$PKG_CONFIG_PATH?  This is an approach
that has served me well for quite some time.

> 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.

I can't see how this wouldn't be solved by ... simply not putting %{prefix}
there.  Let's say you had a module setup (not entirely hypothetical -- I'm
thinking of the Debrix case here):
	prefix=/usr
	modulebase=lib/modules/xorg
	moduledir=%{prefix}/%{modulebase}

This way you get the best of both worlds: $PREFIX support if you want it (just
grab modulebase out of the .pc with the standard interface, and use
$(PREFIX)$(modulebase)), but also fully-qualified paths if you need.

> > 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.

I don't mean to denigrate your skills, work, or intent, but I just really don't
see the point of all this.  I firmly believe that all your problems can be
solved within the scope of the current pkg-config codebase, and that some of the
problems you're trying to solve (interoperability of *-conf) are actually
symptoms of other problems (existence of *-conf).

Without a standard interface, .pc as a format is meaningless: just as .desktop
would be meaningless if everyone used randomly differing fields such that
.desktop files for KDE apps would be totally broken within GNOME.  With its
implementations, .desktop has allowed applications to be launched and contained
within defined structures, and every implementation allows you to launch
applications from within a certain defined structure.

As an application developer, pkg-config provides me with a way to access all the
data from something I depend on (usually a library), within a standard mechanism
(a single defined interface from shell, and a single defined API from within
autotools).  This means that if I depend on a library, and it uses pkg-config,
I can use pkg-config --cflags foo, or PKG_CHECK_MODULES(BAR, foo).  If
pkg-config were extended to have implementation-specific dependencies (i.e., the
standard pkg-config tool cannot usefully parse the .pc for kdefx), then we have
lost, and we might as well go back to the days of freetype-config, gtk+-config,
et al.

I don't see anything in here that, as someone who is mainly responsible for its
implementation within a very large framework with multiple implementations
(xlibs, xserver, debrix[0]), would compel me towards this tool.

[0]: Which has an SDK it provides, allowing external builds of all its modules.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050123/d24b7637/attachment.pgp