[PATCH] for libfoo.py

[Christian Ehrlicher]

> --- Ursprüngliche Nachricht ---
> Von: Christian Ehrlicher <Ch.Ehrlicher at gmx.de>
> An: kde-buildsystem at kde.org
> Betreff: Re: [PATCH] for libfoo.py
> Datum: Tue, 03 Jan 2006 07:14:39 +0100
> 
> David Faure schrieb:
> > On Saturday 31 December 2005 17:46, Christian Ehrlicher wrote:
> > 
> >>+               libjpeg = env.find_file_ext('jpeg'+env['LIBSUFFIX'],
> jpeg_lib_path)
> > 
> > 
> > This patch breaks libjpeg detection for me on unix.
> > 
> > "Checking for libjpeg... (cached) no
> > "libjpeg not found (mandatory).
> > 
> > The (cached) is wrong, I deleted cache/libjpeg.cache.py
> the '(cached)' output is somewhat ugly. I don't know excatly why this is
> printed every time I use context.Result()
> I tried to remove env['CACHED_JPEG'] or set it to 0 but nothing helped...
> > 
> > I added debug output in Check_libjpeg and it says:
> > LIBSUFFIX=.a
> > libjpeg=
> > 
> > The problem is obviously the value of LIBSUFFIX, it should be .so
> > Where does it come from?
> LIBSUFFIX is the suffix of the static libary and SHLIBSUFFIX is for
> dynamic libs. The problem here is that win32 needs the static lib
> (because it's the import lib) and you the dynamic one.
> I've fixed it by explicit specifying the correct extension and will
> think over how to handle this.
> What about linking against a static libjpeg? Should this be possible and
> how to say this bksys?
Another solution would be to skip all the additional include/lib path stuff.
This would mean that you've to specifiy all additional include paths with
extralibs/extraincludes on the command line. Then there is no need to search
for them in libfoo.py
But a lof of the libfoo.py tests used extra include path so I did also.

Christian

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner