On Tue, Feb 13, 2007 at 06:18:54AM +0000, Richard Frith-Macdonald
wrote:
An extra dependency most emphatically IS an issue ... because the
'people' you are referring to actually just means 'you', and you are
just guessing about other users, and even assuming that 'most' is
actually the case, then what you are proposing is to have something
that only works for 'most', not for all. Is your guess that
'most' is
55%, 70%, 95%? At what point is the remaining 45%, 30%, 5%
sufficiently small a minority that they become a non-issue?
First off, pkg-config is a developer dependency. Users of gnustep
applications that have them packaged by their distribution will not
have
to worry about pkg-config. For what it is worth, some of our
dependencies are already using pkg-config (libxml2, sqlite3, libart,
libpng, freetype, etc.).
Second off, as pkg-config is a *developer dependency* far less worry
should be put into making it a dependency. If you are an actual
developer, I'd hope you have the capability to get a few extra
dependencies sorted (especially considering that pkg-config IS
available
on so many distributions at this point).
Dependency issues do not rule out using things (indeed, GNUstep has
plenty of dependencies), but they are a big factor to consider, and
only appear minor to the people they don't happen to effect, so when
adding a dependency we need to be clear that what we are adding has
overwhelming advantages over the alternatives. While pkg-config is
quite nice (and looking at it provides inspiration), it has no such
advantages.
There is one major advantage that pkg-config does provide here and
that
is simply that we are not maintaining it. Everytime we work around
having another standard system service by reimplementing it in our
codebase, sure we save a 'dependency', but at the same time we have
more
code that we have to support and that is never a good thing.