Stricter compatibility checking for GIF dependency

[Paulo Jorge Guedes]

> -----Original Message-----
> From: William A. Hoffman [mailto:billlist at nycap.rr.com]
> Sent: terça-feira, 30 de Maio de 2006 17:14
> To: kde-buildsystem at kde.org
> Subject: RE: Stricter compatibility checking for GIF dependency
> 
> At 06:54 AM 5/29/2006, Paulo Jorge Guedes wrote:
> >> -----Original Message-----
> >> From: Adriaan de Groot [mailto:groot at kde.org]
> >> Sent: quarta-feira, 24 de Maio de 2006 22:27
> >> To: kde-core-devel at kde.org; kde-buildsystem at kde.org
> >> Subject: Stricter compatibility checking for GIF dependency
> >>
> >> I have a Kubuntu system where I installed the first GIF library I
> >spotted
> >> --
> >> one called giflib3g. This passes the configure tests and installs
> >> a /usr/include/gif_lib.h but the library is not compatible with KHTML
> >> because
> >> it is missing GifFileType member UserData. Switching to libungif4
> >resolves
> >> that. Can a check for that member variable be added to kdelibs'
> >configure
> >> checks to ail out before compilation?
> >
> >The check is failing here with mingw because it can't find the header
> >"gif_lib.h".
> >This doesn't happen with msvc because the gnuwin32 include path is in
> >the INCLUDE env variable, while on mingw I have it set in the
> >CMAKE_INCLUDE_PATH. Shouldn't cmake honor that and pass the paths in
> >CMAKE_INCLUDE_PATH to the TRY_COMPILE command?


> If you look at the dashboard this check is breaking OSX and Windows
> builds.

I noticed but thought it was not relevant for the case.

> If you have to use a try compile for this test, I think it should first
> try
> to locate the header file, and pass the include directory into the try
> compile.

But my question remains. Shouldn't CMAKE_INCLUDE_PATH be taken in consideration?

Paulo