[CMake] PKGCONFIG backward compatibility on CVS trunk.

[Alan W. Irwin]

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
>   # 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.

Let me give some background for the reasons why I submitted that patch.

There is a whole new approach to pkg-config in the CVS version of CMake with
the PKG_CHECK_MODULES and PKG_SEARCH_MODULE modules having powerful new
features compared to the traditional PKGCONFIG module which is now declared
obsolete with this new approach.

Clearly, PKGCONFIG has been implemented in the new approach to keep some
sort of backwards compatibility with previous releases, but when I tried to
build PLplot with the CVS version of cmake I noticed there were some
compatibility problems with PKGCONFIG (e.g., returning lists rather than
blank delimited strings such as in 2.4.5) which my patch fixed and which
Bill has apparently applied to CVS.

Of course, those who have been using PKGCONFIG from CVS and adjusted to
the backwards incompatibilities before my patch was applied will notice
my changes.

So the real question here is whether you are going to break compatiblity
with 2.4.5 and previous release for the PKGCONFIG macro (now labelled
obsolete) or are you going to break compatibility for CVS users who have
already adjusted to the CVS version of PKGCONFIG before my patch and who
have decided for whatever reason not to use the recommended
PKG_CHECK_MODULES and PKG_SEARCH_MODULE modules?

Ultimately, the decision on this question is one that Bill and the rest of
the cmake developers have to take.  If it comes down on the side of
preserving backwards compatibility for the PKGCONFIG macro with previous
releases, then I would appreciate people trying the CVS version to make sure
my implementation of this is correct and no changes in PKGCONFIG use have to
be made between 2.4.5 and the CVS version.

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 about maintaining backwards compatibility since I don't like to put
up too many barriers to changes and improvements in CMake or any other
open-source projects.  Thus, I am willing to pay that price of adjusting the
PLplot configuration scripts if that is how the decision unfolds.  The only
thing I really ask for is clear release notes that tell exactly where
backwards compatibility has been compromised.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________