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
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake