Dependency changes and release schedule for QOF 0.6.4

[Neil Williams]

On Thursday 06 April 2006 3:27 pm, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > The way QOF handled #include <glib.h> and other library headers in
> > previous versions has led to applications depending on libqof having
> > spurious dependencies and these cause packaging errors. (binary X links
> > against library Y but does not use any symbols).
> >
> > This has been fixed in QOF CVS by preventing QOF headers from
> > transparently including indirect dependencies - in the case of gnucash
> > this means that #include <qof.h> no longer implicitly includes <glib.h> -
> > and by fixing the pkg-config file to make QOF dependencies (like glib)
> > private to qof. The pkg-config --libs line is now just:
> > -lqof
> >
> > (Before it referenced -lz, -lm, -lgda2, -lglib-2.0 and others, all of
> > which simply duplicated the symbols from other libraries.)
>
> Please don't change this.  pkg-config --libs libqof should give me
> EVERYTHING I need properly link libqof. 

That is (now) what it does. Before it brought in large numbers of unnecessary 
libraries. I cut the pilot-qof dependency list by 50% with this change.

It is not scalable *at all* for packages to build-depend on all
libraries referenced indirectly anywhere in the dependency tree.

> It should not be the job of 
> every user of your library to figure out what your build-time
> dependencies are....

? I can't do everything - it is up to the user to identify the build-time 
dependencies. It is with libglib-2.0, it is with libgda2-3 and it is with 
libqof1 (>= 0.6.4).

I provide the information on the qof website and each qof programme acts as an 
example. qof-gen will expand these examples.

The problem was <= 0.6.3 where the pkg-config was basically lying to the 
users.

> Unless, of course, I don't need to link against 
> -lgda2 when I link against -lqof?

No, you don't. This behaviour is explicitly designed to prevent binaries being 
linked against completely unnecessary libraries. 

Neither did you ever need -lm, -lz or any of the others.

This change was done because of packaging warnings about unnecessary 
libraries - the whole point is that what has been removed is already 
determined as unnecessary.

lgda2 isn't even available on some platforms that already run libqof1 (OSX). 
I'd already dealt with that via ${added_libs} but this has also been improved 
by making it Requires:private in pkg-config.

> I.e., I should be able to just use the libqof pkgconfig library list
> to link against a qof app.  I shouldn't have to know e.g. glib2.

Of course you'll have to link against glib-2.0 to use glib routines - the 
point is that libqof should not and cannot do this for you. It's an indirect 
dependency.

It is - and should remain - possible to redefine certain glib defines and 
prototypes in an external header such that libqof can be built without the 
current glib. This allows libqof1 to remain available if, e.g. libglib moves 
to glib-3.0.

The user can simply change their own build environment to use glib-3.0 - 
libqof1 should not then go and add glib-2.0 behind your back. That's the 
problem we currently have with guile-g-wrap:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359299

guile-g-wrap should not depend on glib-1.2. Preferably, with upstream changes, 
it shouldn't even depend on glib-2.0. That choice should be up to the user - 
albeit with some backported changes to handle glib-1.2 routines that may have 
been removed from libglib-2.0.

This is how I work with pilot-link 0.11.8 and 0.12 - I've had to backport 0.12 
code to pilot-qof so that it can work with 0.11.8.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060406/0824ac21/attachment.bin