On Thursday 06 April 2006 3:27 pm, Derek Atkins wrote: > Neil Williams <[EMAIL PROTECTED]> 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/
pgp1PMR6IrGwk.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
