[ghemical-devel] pkg-config?

Michael Banck mbanck@gmx.net
Fri, 11 Apr 2003 11:55:55 +0200


Hi,

On Fri, Apr 11, 2003 at 10:55:13AM +0300, Tommi Hassinen wrote:
> On Thu, 10 Apr 2003, Michael Banck wrote:
> 
> > I had another look at libghemical. Some comments, I don't know if I
> > wrote that earlier already:
> >
> > 1. You don't seem to build a shared library of libghemical. That would
> >    be quite required I guess
> 
> The only problem is that I'm not really very familiar with either types of
> libraries (static/shared). I assume that a shared library is made using
> object files, in a similar way like a static library. Is there any extra
> requirements that need to be considered?

Debian policy dictates that shared libraries be compiled with -fPIC,
while static one should be not. I don't know any other requirements
off-hand.

Oh yeah: shared libraries have an interface version which is totally
independant of the package version. This would be e.g.
libghemical.so.1.0.0, so one can install multiple versions of a shared
library. OTOH, this means that you'll have to be more careful about
changing interfaces and in case you do, you'll have to change the
SO-name of the library. The libtool info-manual has more information
about this.

> > 2. Why do you include miniMOPAC? Wouldn't it be better to split that
> >    off, perhaps as a slowly crawling sourceforge-project (or on
> >    bioinformatics, I don't care)
> 
> A good idea. I'll start working on this.
 
great.

> In the app package, we also still have the built-in copy of OpenBabel. We
> could use it as a library as well, once OB's library support is ready. Or
> is it already?
 
Openbabel does not provide a shared library yet, because of a
fluctuating interface.

> > 3. Did you consider using automake?
> 
> Sorry, I'm not familiar with this either. Could you briefly explain what
> would be the benefits of automake?

Well, you just tell automake 'These are the source files, these are the
header files, these files would have to go into a tarball as well and
please name the resulting library libghemical' and it will take care
about the rest. Integrating libtool is easy for simple libraries like
libghemical, so you'd get shared library support almost for free, you
just need to tell libtool the library-version in configure.in.

> > that pc file then gets installed in $(DESTDIR)$(libdir)/pkgconfig, so I
> > guess that could be anywhere you like.
> 
> Yes, but it must be a place where pkg-config can find the file; I wondered
> whether it looks both /usr/lib/pkgconfig and /usr/local/lib/pkgconfig.

open("/usr/local/lib/pkgconfig", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3

It looks like it does.
 
> > Well, gchemutils (gcu.pc) e.g. does it like you say above:
> >
> > prefix=@prefix@
> > exec_prefix=@exec_prefix@
> > libdir=@libdir@
> > includedir=@includedir@
> >
> > Name: GtkPeriodic
> > Description: A Mendeleiev table widget for GTK+-2.0
> > Version: @VERSION@
> > Requires: gtk+-2.0
> > Libs: -L${libdir} @GCU_LIBS@ -lgtkperiodic -lgcu @gtkcrystalviewer@
> > Cflags: -I${includedir}/gcu @GCU_CFLAGS@ @gl_flags@
> 
> Yep, the .pc files are short ones, about a dozen lines like the one above.
> 
> I thought that perhaps the .pc file could be written in the configure
> script. I made a following test script:
> 
> 	#! /bin/bash
> 	rm test.pc
> 	echo this is line 1 >> test.pc
> 	echo homedir = $HOME >> test.pc
> 	echo this is line 3 >> test.pc
> 
> The script makes a test.pc file:
> 
> 	this is line 1
> 	homedir = /home/thassine
> 	this is line 3

You can either do this, or just have a test.pc.in in which only the
@VARIABLES@ get substituted by configure as it generates test.pc out of
it.

Michael