-------- Original-Nachricht -------- Datum: Tue, 05 Dec 2006 21:04:23 +0100 Von: Michel Hermier <[EMAIL PROTECTED]> An: [EMAIL PROTECTED] Betreff: Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.
> Bill Hoffman wrote: > > Michel Hermier wrote: > >> Hi, > >> > >> I'm experiencing a string against list issue PKGCONFIG new code. > >> > >> When using it we (in KDE) do things like: > >> > >> PKGCONFIG(lib libIncDir libLinkDir libLinkFlags LibCFlags) > >> FIND_PATH(LIB_INCLUDE_DIR libfile.h ${linInkDir}) > >> FIND_LIBRARY(LIB_LIBRARIES NAMES libnames ... PATH ${libLinkDir}) > >> > >> This was working for me until the upgrade of the pkgtool util. > >> > >> It seems that the new pkgtool util return a string instead of a list, > >> making the FIND_FOO methods fails in case of multiple path. > >> From what I understand, calling ${BAR} doesn't produce the same > >> number of arguments when expended, and for me it's sounds an > >> unexpected behavior. > >> I mean, if I wanted it to be a single argument I would have done > >> "${BAR}" > >> > >> I attached a little CMakeLists.txt that show the behavior. > >> The case is simple I only assign one variable to one string, and one > >> to a list containing the same content of the string. > >> And the output is different of the 2 calls is different, while I > >> would expect to have the same output since I don't used "" in the > >> macro call. > >> > >> Is it something expected or did I miss something ? > > I am a bit lost here.... > > > > Did the program pkgtool change its output? If not, then it was not > > intentional to break backwards compatibility with the new pkgconfg > stuff. > > > > A patch was submitted because PlPlot did not work with the changes... > > > > Here is the comment: > > > > # To be compatible with obsolete module must return blank-delimited > > strings. > > # Also, lead with a blank (for TRUE/FALSE compatibility, 2.4.4 > > appears to > > # have returned a blank sometimes followed by nl for the situation > > # where the pkg-config module has been found [e.g., > > _PKGCONFIG_TMP_FOUND] > > # but does not define the desired quantity. > > > > The old one basically did this: > > EXEC_PROGRAM(${PKGCONFIG_EXECUTABLE} ARGS ${_package} --libs > > OUTPUT_VARIABLE ${_link_FLAGS} ) > > > > The new one puts it in a cmake list, but the patch puts it back into a > > string separated by spaces. > > > > -Bill > > > > > I'm not sure of it, but in usage it seems every one expects it to be a > list, else it's a nonsense to use the returned value everywhere I > explained before. The error was triggered for me while checking a > package with a parent package dependency (QCA2 in trunk). So maybe the > Find*.cmake scripts were/are still doing wrong ? > AFAIK we are still require CMake-2.4.4 for kde4, should we force to have > 2.4.5 and changes the scripts to use the new macro so that this error is > avoided ? We are still requiring CMake 2.4.3 and I don't see a real reason for chaning this currently (except for Windows developers, for them I'll probably raise this 2.4.5 soon). I think the "old" (old as in existed since maybe 9 months or so) pkgconfig() macro really should stay compatible, the newline problem should be fixable. Bye Alex -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake