[Digikam-users] Fwd: Re: Exiv2 library missing???

[Angelo Naselli]

Alle 10:14, venerdì 8 dicembre 2006, Thorsten Schnebeck ha scritto:
> On Thursday, December 7, 2006 02:50:36 PM Angelo Naselli wrote:
> 
> > > > > You have to options:
> > > > > 1) Try to convince the kipi-devels that the current kipi
> > > > > configure-checks is bad style
> >
> > To convince us, they should propose something better and they should
> > argue why it's bad style, or am I wrong?
> 
> Hi Angelo,
> 
> the discussion was a "little" bit longer, so you don't have enough information 
> so far:
> 
> The aim is to install a test version of digikam and all of its components into 
> a separate directory. That way you have a stable version and a test version.
I see, but of course that is a "developing" issue.
I maybe wrong and I'm going to check it better because a lot of autotools stuff
are often reworked by kde admins one, but there is a standard way to "influence"
configure script behavior, e.g. changing environment variables. 
> 
> Problem is to install two versions of exiv2-lib. Here are some side effects. 
> dikikam checks for exiv2 by searching for exiv-config and check its version 
> by using pkg-config.
> 
> So if you want to differentiate two version of libexiv2 you need to adjust
> your  PKG_CONFIG_PATH env variable.
And that imo should be the right way to.
> 
> But kipi-check destroys/adjusts your PKG_CONFIG_PATH:
hmm I'll check it, if so the wrong behavior is there, not in the exiv2 test. 
> 
> > #------------------------------------------------------------------
> > # KIPI support (KDE Image Plugin Interface)
> > #------------------------------------------------------------------
> > 
> > if test "$PKGCONFIGFOUND" = "yes" ; then
hmm if I'm not wrong that is the way it's used by digikam, amarok and kipi & co.
to be honest I don't like adding a way to overwrite standard way though.
> >    # check for libkipi
> >    have_libkipi=no
> > 
> >    PKG_CONFIG_PATH="$prefix/lib${kdelibsuff}/pkgconfig:$PKG_CONFIG_PATH"
> >    if test "$prefix" != "$kde_libs_prefix"; then
> >        PKG_CONFIG_PATH="$kde_libs_prefix/lib${kdelibsuff}/pkgconfig:
> > $PKG_CONFIG_PATH"
> >    fi
> >    export PKG_CONFIG_PATH
hmm reading the above code it seems not to override anything, it simply
add as first entry the $prefix/lib... path. Again if I'm not wrong we're
talking about configure script so --prefix change the install path and
$prefix variable. So what you saw it's a way to say to configure to find
first pkgconfig directory in your installation directory and after that
int the standard one.
Let's say you're using ./configure --prefix=$HOME/KDE/INSTALL,
PKG_CONFIG_PATH will be "/home/yourhome/KDE/INSTALL/lib/pkgconfig:old_path"
So if you use a PKG_CONFIG_PATH=/my/optional/installation/lib/pkgconfig:/usr/lib/pkgconfig
and run configure again you should change the beahvior as you like.
> 
> If your stable version of libexiv2 stays in $prefix/lib${kdelibsuff} you can 
> not use another lib version cause KIPI support overwrites PKG_CONFIG_PATH.
I don't get it sorry. If I'm not wrong libexiv can't be compiled togheter
kipi & co or digikam or... It's a different package/project. So you should use
./configure --prefix=/my/optional/installation/ for exiv and cahnge your PKG_CONFIG_FILE
variable should work for other projects. Am I missing something?
> 
> I called this bad style cause when studying other configure check I often saw 
> this style:
> 
> pkgconfig_save=$PKG_CONFIG_PATH
> PKG_CONFIG_PATH=(what ever I need)
> (do some tests)
> PKG_CONFIG_PATH=$pkgconfig_save
We can add some more tests, but why? IMO the standard way should be enough.
If you use LD_LIBRARY_PATH you change the use of dinamic libraries right?
so using PKG_CONFIG_PATH you should reach your aim. If that does not work
then I agree there's a problem and we must fix it. But I've just had a
report from a kipi-plugins user that using PKG_CONFIG_PATH  and LD_LIBRARY_PATH 
makes the trick, so I'm not sure it doesn't.
 
> But KIPI support exports this changed environment variable.
> 
> Solutions to solve this problem:
> 
> 1) a save redefinition like:
> PKG_CONFIG_PATH="$PKG_CONFIG_PATH:$prefix/lib${kdelibsuff}/pkgconfig"

> 2) digikam uses exiv2-config and not pkg-config
from digikam configure.in.in
 #------------------------------------------------------------------
# Check for Exiv2 library
#------------------------------------------------------------------

have_exiv2='no'
AC_PATH_PROG(EXIV2_CONFIG,exiv2-config)
if test -n "${EXIV2_CONFIG}"; then
  EXIV2_CFLAGS="`$EXIV2_CONFIG --cflags`"
  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)
fi

from kipi-plugins one
#------------------------------------------------------------------
# Check for Exiv2 library
#------------------------------------------------------------------
have_exiv2='no'
AC_PATH_PROG(EXIV2_CONFIG,exiv2-config)
if test -n "${EXIV2_CONFIG}"; then
  EXIV2_CFLAGS="`$EXIV2_CONFIG --cflags`"
  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)
fi

I don't see any difference. Before using exiv2-config we used a
test on a file (hpp) IIRC, that was not very good imo.
> 3) pkgconfig_save method without exporting
Try the solution i proposed and tell me if it's wrong and we'll
see where and if we have to change anything.


Angelo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20061208/3b19edca/attachment.sig>