> -----Original Message----- > From: William A. Hoffman [mailto:[EMAIL PROTECTED] > Sent: terça-feira, 30 de Maio de 2006 17:14 > To: [email protected] > 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:[EMAIL PROTECTED] > >> Sent: quarta-feira, 24 de Maio de 2006 22:27 > >> To: [EMAIL PROTECTED]; [email protected] > >> 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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
