[CMake] PKGCONFIG backward compatibility on CVS trunk.

[Michel Hermier]

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 ?

Michel