[Kde-imaging] libkexif

Renchi Raju renchi at pooh.tam.uiuc.edu
Tue Jul 27 16:45:51 CEST 2004



On Mon, 26 Jul 2004, Achim Bohnet wrote:

> 	o config.h is included public header file kexifentry.h
> 	  AFIAU config.h should only be used to build libkexif
> 	  not whan it is used.

fixed.

>
> 	o configure default is to use -rpath by default and it's installed
> 	  into /usr/local/lib.  IMVHO disable it by default is
> 	  better if by default libs don't go into a 'non' standard
> 	  dir.

don't know enough to say anything intelligent on this right now. i will
dig up some info and reply to this later.

> 	o include dir is /usr/include/libkexif not /usr/include,
> 	  /usr/include/libkexif0.  (Well, my favorite would be
> 	  /usr/include/kde3/)

libkexifincludedir = $(includedir)/libkexif
this can be customized by a debian packager by using debianrules in the
admin section (see how for eg, kdebase is packaged).

> 	  If you prefer to stick with /usr/include/libexif, I would
> 	  suggest to document if -I/path/libkexif or #include <libkexif/...>
> 	  should be used.  AFAIR it was mandrake that put obex stuff into
> 	  /usr/include instead of a obex subdir and this broke code using
> 	  #include <obex/...>  for kdebluetooth.  Would be nice if libkexif
> 	  could prevent this trouble right from the start ;)

currently we (digikam and kipiplugins) are the only ones using digikam.
and we use #include <libkexif/...>. anybody looking at the src
for examples will/should follow this trend.

> 	o kexifutils.h uses #include "kexifdata.h".  Because kexifdata.h
> 	  is also installed into /usr/include shouldn't this be
> 	  #include <kexifdata.h>?

cosmetic issue: "include.h" means file in current directory. <include.h>
means file not in current dir. for kexifutils.h, kexifdata.h is in current
directory. so the current setup is correct.

> 	o <stupid-question> the installed *.h files corresponds to the
> 	  *.cpp in the source.  From a developers POV isn't just one/or two
> 	  kexif.h 'enough' for a small library like libkexif? </stupid-question>

how does it matter? only four headers (not all) are installed and all of
them correspond to different classes, which are needed by a developer to
make full use of the library.

> 	o libkexif is not linked against libqt-mt or any kdelib.
> 	  Is this done on purpose?
> 	  At least debian requires a shared lib is linked against
> 	  all shared libs it depends on. See 3 paragraph of
> 		http://www.de.debian.org/doc/debian-policy/ch-files.html#s-libraries
> 	  Why is also described there (dlopen usage).

fixed.

thanks,
renchi


More information about the Kde-imaging mailing list