[CMake] PLplot issues with the cvs version of CMake (wxwidgets)

[Alan W. Irwin]

On 2008-03-20 15:04-0700 Alan W. Irwin wrote:

> Thanks for pointing out that empty -I.  I will track down why the cvs
> version of CMake does that (while 2.4.8 does not) and get back to you. In
> any case, it sounds like this PLplot/CMake cvs problem has nothing to do
> with the above issue with libraries specified without their full path name.

The difference is caused because FindwxWidgets delivers
wxWidgets_DEFINITIONS as a blank delimited string for 2.4.8 and as a list
for the cvs version.  PLplot had the following problematic code which depended
on the blank delimitation:

string(REGEX REPLACE ";" " -I"
wxwidgets_COMPILE_FLAGS
"-I${wxWidgets_INCLUDE_DIRS} ${wxWidgets_DEFINITIONS}"
)

For 2.4.8 this simply appended wxWidgets_DEFINITIONS to the transformed
wxWidgets_INCLUDE_DIRS list since wxWidgets_DEFINITIONS was blank delimited.
For the cvs version, wxWidgets_DEFINITIONS (now a list) got transformed as
well.

The PLplot fix is the following code:

string(REGEX REPLACE ";" " -I"
wxwidgets_COMPILE_FLAGS
"-I${wxWidgets_INCLUDE_DIRS}"
)
# For case (cvs version of CMake as of 2008-03-23, but not cmake-2.4.8)
# when wxWidgets_DEFINITIONS is a list.
string(REGEX REPLACE ";" " "
wxwidgets_COMPILE_FLAGS
${wxwidgets_COMPILE_FLAGS} 
" ${wxWidgets_DEFINITIONS}"
)

I would like to make some generalizations about modules and backwards
compatiblity that have been sparked by this issue.

In general, I applaud moving from blank-delimited results to lists as has
happened for wxWidgets_DEFINITIONS, but this issue was caused by a backwards
incompatibility in FindwxWidgets.cmake that caught PLplot (before the above
fix which works for both blank-delimited and list versions of
wxWidgets_DEFINITIONS) and which _might_ catch others. That said, my own
feeling is that rigid insistence on backwards compatibility for modules is a
strait-jacket for further module development _for the present release model_
(where the modules are released as part of the CMake release).

To get around this problem, I believe that modules should have their own
independent releases.  That should allow PLplot, for example, to
conveniently move to the CVS version of CMake while still using the 2.4.8
modules (which should still work because rigid backwards compatibility is
built into the non-module part of CMake).  By definition, if a project
always used the 2.4.8 modules, no backwards incompatiblities would be
introduced by the modules. OTOH, with this suggested change in how modules
are released, module maintainers can go ahead and improve things without
worrying about strict backwards compability, and if a project like PLplot
decides to move to later module versions we are free to do so if we are
willing to pay the price of adjustments to our code as above.

In sum, Bill, I hope you consider making separate module releases to
absolutely insure backwards module compatibility for those who stick with a
particular module release while being allowed to change cmake version.  This
would also have the simultanous benefit of freeing the module developers to
get on with improving the modules without enforcing strict backwards
compatibility.

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 libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________