[Kde-imaging] exiv2 (Re: extragear/libs/kipi-plugins)

[Caulier Gilles]

Le Vendredi 8 Décembre 2006 19:46, Angelo Naselli a écrit :
> Alle 17:26, venerdì 8 dicembre 2006, Fabien ha scritto:
> > Hi,
> >
> > Fabien wrote:
> > > Angelo Naselli wrote:
> > >>>Using my script (compile_digikam.txt
> > >>>http://www.digikam.org/?q=download/svn), it doesn't work (exiv2 is
> > >>>installed in a non-default directory).
> > >>>
> > >>>I had to use "export PKG_CONFIG_PATH=$DIGIKAMDEST/lib/pkgconfig" to
> > >>> make it work.
> > >>
> > >>That should be the right way to.
> >
> > With the tests I made about digikam, exiv2 and local compilation when
> > exiv2 is already installed in the system (see digikam-users ml), I know
> > a bit more about all this stuff :)
> >
> > So, about the problem I reported a few days ago, I think it would be
> > better to use KDE_PKG_CHECK_MODULES instead of PKG_CHECK_MODULES in :
> > libs/kipi-plugins/configure.in.in for the exiv2 test.
>
> That sounds more KDE compliant ;)
> Yes I believe you're right. At this point exiv it's not the only
> PKG_CHECK_MODULES test but we've also libgpod in kipi-plugins.
> Gilles I've checked also in digikam configure.in.in and you've
> got also sqlite3. So you need probably to change that as well.

right. Propose  me a patch if you can ...

>
> > It would be more consistent as it's already used by kipi-plugin test.
> > Like that, we don't need to define PKG_CONFIG_PATH anymore...
> >
> >
> > Here's the proposed patch :
> >
> > Index: configure.in.in
> > ===================================================================
> > --- configure.in.in     (revision 611531)
> > +++ configure.in.in     (working copy)
> > @@ -138,7 +138,7 @@
> >     AC_SUBST(EXIV2_CFLAGS)
> >     LIB_EXIV2="`$EXIV2_CONFIG --libs`"
> >     AC_SUBST(LIB_EXIV2)
> > -  PKG_CHECK_MODULES(EXIV2, exiv2 >= 0.12, have_exiv2=yes,have_exiv2=no)
> > +  KDE_PKG_CHECK_MODULES(EXIV2, exiv2 >= 0.12,
> > have_exiv2=yes,have_exiv2=no) fi
> >
> >   if test "x$have_exiv2" != "xyes"; then
>
> Fabien, this patch it's ok for me I will commit asap.
>
> Gilles talking about touching configure.in.in, we should increase the
> libkipi dependency, since I believe we cannot build kipi-plugins with
> libkipi < 0.1.5, e.g. the last one. Am I wrong?

We can make some rules in the code to check the libkipi version with some 
#ifdef... but, it will be more complicated.

I'm agree to fix libkipi depency of kipi-plugins to the current version.

Gilles