[CMake] PKGCONFIG backward compatibility on CVS trunk.

Bill Hoffman bill.hoffman at kitware.com
Tue Dec 5 16:54:29 EST 2006


Michel Hermier wrote:
> Bill Hoffman wrote:
>> Michel Hermier wrote:
>>>
>>>>
>>> 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
>>>
>> Do you have a case where something works in CMake-2.4.4, but does not 
>> work in CVS CMake that uses UsePkgConfig.cmake?
>> If so, we will fix it.  If this is new stuff, we can not change 
>> UsePkgConfig.cmake because it will break old code.   There should
>> be no change in this stuff from 2.4.4 and 2.4.5, so either should 
>> work the same.  The new module is currently only in CVS.
>>
>> -Bill
>>
> I checked the generation of the qca.pc file and it was not updated for 
> 2 month so it was definitely working before the update. And to be 
> really sure I reverted to the old file, and now it works again for me 
> and when I look at the code again, it definitely doesn't do the same 
> thing.
> It seems the code don't react on the correct variables. It use 
> _PKGCONFIG_TMP_INCLUDE_DIRS and _PKGCONFIG_TMP_LIBRARY_DIRS, where it 
> should use the _PKGCONFIG_TMP_INCLUDEDIR and _PKGCONFIG_TMP_LIBDIR, 
> well at least the correct variable seted by pkg-config arguments wich 
> are --variable=includedir and --variable=libdir.
> Hope I digged enougth so that it can be correct ;)
We are getting closer I am sure.... But, I am still not clear what the 
problem is here....
What variables are wrong and what should they be?

Thanks.
-Bill


 


More information about the CMake mailing list