Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

Alan W. Irwin wrote: Anyhow, could we finish off this issue? I hate to see something so close to solution hang fire like this. OK, done, I remove the PKGCONFIG from FindPkgConfig, and added the deprecated message in UsePkgConfig, and reversed it to its old way of doing things. If you run into

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

On 2006-12-08 19:17-0500 Bill Hoffman wrote: Michel Hermier wrote: Anyway maybe the inclusion of the file should also be restricted by some version compatibility checking ? So that a project say by macro that it requires a 2.4.5 compatibility and only warn about the deprecated helper file

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

Michel Hermier wrote: Anyway maybe the inclusion of the file should also be restricted by some version compatibility checking ? So that a project say by macro that it requires a 2.4.5 compatibility and only warn about the deprecated helper file and/or macro, while a macro not saying it will

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

Michel Hermier wrote: Alan W. Irwin wrote: It appears the 2.4.5 version of UsePkgConfig.cmake is what you need. I therefore believe the current approach in cvs (although it works consistently for PLplot for 2.4.5 and cvs version) is attempting the impossible; emulate the old behaviour by using

Re: Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

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, >

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

Alan W. Irwin wrote: It appears the 2.4.5 version of UsePkgConfig.cmake is what you need. I therefore believe the current approach in cvs (although it works consistently for PLplot for 2.4.5 and cvs version) is attempting the impossible; emulate the old behaviour by using the modern macros with

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

On 2006-12-05 20:09-0500 Bill Hoffman wrote: Alan W. Irwin wrote: Therefore, I suggest the following improved proposal to take care of these compatibility issues exactly. 1) Copy the 2.4.5 UsePkgConfig.cmake which defines the PKGCONFIG macro to CVS with the only change being to add a message t

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

Alan W. Irwin wrote: On 2006-12-05 23:51+0100 Michel Hermier wrote: Alan W. Irwin wrote: On 2006-12-05 22:31+0100 Michel Hermier wrote: 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 n

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

On 2006-12-05 23:51+0100 Michel Hermier wrote: Alan W. Irwin wrote: On 2006-12-05 22:31+0100 Michel Hermier wrote: 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 c

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

Alan W. Irwin wrote: On 2006-12-05 22:31+0100 Michel Hermier wrote: 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 o

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

On 2006-12-05 16:54-0500 Bill Hoffman wrote: 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 defi

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

On 2006-12-05 22:31+0100 Michel Hermier wrote: 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 shoul

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

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

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

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 (QCA

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

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

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

Alan W. Irwin wrote: On 2006-12-05 13:32-0500 Bill Hoffman wrote: OTOH, if they decide to revert my patch from CVS and break backwards compatibility with previous releases, then I (and lots of other CMake users) will have to adjust our use of the PKGCONFIG module. I am not actually a fanatic

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 NAME

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

On 2006-12-05 13:32-0500 Bill Hoffman wrote: 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

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

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 $

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

On Tuesday, 5 December 2006 18:31, Michel Hermier wrote: > Is there a macro to split a string to a list, so that > the compatibility macro at least could get fixed ? > Maybe a utility commands like STRING SPLIT/JOIN should be added for that > ? and maybe there are other more usage for it ? $ cmake

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

David Cole wrote: On 12/4/06, *Michel Hermier* <[EMAIL PROTECTED] > wrote: set (FOO "foo bar") dump (${FOO}) Here FOO is a string that contains a space... set (FOO foo bar) dump (${FOO}) Here FOO is a list with two elements. If it were printed a

Re: [CMake] PKGCONFIG backward compatibility on CVS trunk.

On 12/4/06, Michel Hermier <[EMAIL PROTECTED]> wrote: set (FOO "foo bar") dump (${FOO}) Here FOO is a string that contains a space... set (FOO foo bar) dump (${FOO}) Here FOO is a list with two elements. If it were printed as a string it would be "foo;bar" HTH, David __

[CMake] PKGCONFIG backward compatibility on CVS trunk.

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