[Kde-imaging] New libkipi 0.1.4

[Angelo Naselli]

Alle 12:25, mercoledì 17 maggio 2006, Michael J Gruber ha scritto:
> Angelo Naselli venit, vidit, dixit 2006-05-17 10:43:
> >> Fixing the libjpeg thing leaves you with a libgcrypt error, fixing that
> >> with a libgpg-error.la. I seem to remember that with rc1, only libjpeg
> >> gave trouble, the other two appeared with rc2.
> > hmm, Achim do you think we've missed some library tests in configure.in.in?
> 
> I think that looks sane.
What I meant is that if libjpeg is not present/found the related plugins 
shouldn't be built.
 
> Tried with LDFLAGS, CFLAGS, CXXFLAGS, CPPFLAGS, LD_LIBARRY_PATH and
> KDEDIRS, even though --with-extra-libs and --with-extra-includes should
> take care of that. The problem seems to be that some libs are installed
> in /opt/kde3, but without the headers; for these packages I have libs
> and headers in $HOME/{lib,include}. I noticed that configure picks up
> libkexif from /opt/kde3, for example, even though it is installed
> locally, too.
kde needs to run kbuildsycoca to have the right kde optional path.
BTW I'm not sure   --with-extra-XXX is better, running something
like 
"LDFLAGS="-L/path/to/my/libs $LDFLAGS"; CFLAGS=xxx;CXXFLAGS=yyy; ./configure someoptions"
should force to have your path first....
 
> I guess most people will have either libs+includes globally or none
> globally (and libs+includes locally), so my setup is not common (and not
> my choice...).
the aim should be to use yours locally first and if not found locally
look for the system ones. Of course all the people who wants to
test svn/cvs projects can be in your situation if he/she doesn't
want to risk to compromise his/her system.
 
Agree though it's not always easy to manage :)

Angelo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-imaging/attachments/20060517/cca490bc/attachment.pgp