Re: [Nemiver-list] pkg-config files and dependencies

["Jonathon Jongsma" <jonathon jongsma domain hid>]

On 10/23/06, dodji Seketeli <dodji domain hid> wrote:
> Hey hey,
>
>
> On 10/23/06, Jonathon Jongsma <jonathon jongsma domain hid> wrote:
> > I'm putting together some pkg-config files for the libraries that we
> > use in nemiver so they can be used by other applications as well.
>
> Excellent !
>
> > Currently, I'm planning to make one for the libnemivercommon library,
> > one for the dbgengine 'library' (really just the IDebugger header)
> > which has a dependency on libnemivercommon, and a .pc file for the gdb
> > backend (libgdbmod).
>
> libnemivercommon.pc is okay.
> libgdmod.so though,  is something not "public". Users are expected to
> link explicitely with libnemivercommon only. So only
> libnemivercommon.pc should be provided.
> To load libgdmod, the user uses the DynamicModule interface and never
> specifies libgdbmod itself.

I agree, but should there be a way to determine which backend plugins
a user currently has installed?  An application author could use a
nemiver-gdb-plugin.pc file (currently called libgdbmod.pc)  to
determine whether the gdb backend was available (or a
nemiver-python-plugin.pc, etc).  But if we do that, we should change
it so that it doesn't return any libraries to link against (I don't
know what I was thinking when I did that).  So it would just be a
simple dependency existence check.  Does that sound useful or not?

what about the libdbgengine.pc file?  that's the one that simply adds
the include path for the IDebugger header to your CFLAGS.  Do you want
to keep that one?  or combine it with libnemivercommon somehow?

> > I was trying to come up with the dependencies to list in the
> > "Requires:" line of the pc files.  Right now we don't have a good list
> > of dependencies for any of the sub-libraries.  Our makefiles just pass
> > all of the libraries and cflags to all of the subdirs (NEMIVER_LIBS
> > and NEMIVER_CFLAGS, which includes everything), but I was wondering if
> > we want to only pass the explicit dependencies to each of these
> > sub-libraries so that things don't get linked in unnecessarily (i.e.
> > if you do `ldd libnemivercommon.so`, it shows everything from avahi to
> > gnome-print, etc).
> > It also seems to me that it would be good if libnemivercommon only
> > depended on glibmm.  There's currently a reference to glade in there,
> > but it's only a helper function to get the directory where glade files
> > are kept, so that shouldn't be a problem (I removed the only
> > libglademm #include that I found since we weren't using any symbols
> > from libglademm there).  The only other problem is a gnome_vfs_init()
> > and gnome_vfs_shutdown() in the file nmv-initializer.cc.
> > I think it
> > would be nice to get rid of this dependency in libnemivercommon, but I
> > haven't yet looked into whether there's another good place to
> > initialize gnome-vfs. Any objections to trying to remove this
> > dependency?
>
> You are right. Each lib should be linked against what's strictly
> needed. I have to look into why we have such a huge dependencies list.
> Man, avahi ... that's nonsense :-) .

Yeah, I think that's just because of the following line in
src/common/Makefile.am:

libnemivercommon_la_LDFLAGS= NEMIVER_LIBS@

So we tell it to link against every single library we check for in
configure.  If we changed that instead to something like:

libnemivercommon_la_LDFLAGS= GLIBMM_LIBS@

then it probably wouldn't link against all of that other stuff.  But
that means that we have to be more diligent about keeping the
dependencies up-to-date.

--
jonner