[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