[CMake] PKGCONFIG backward compatibility on CVS trunk.

[Alexander Neundorf]

-------- Original-Nachricht --------
Datum:  Tue, 05 Dec 2006 21:04:23 +0100
Von: Michel Hermier <michel.hermier at gmail.com>
An: billlist at nycap.rr.com
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