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

[Miguel A. Figueroa-Villanueva]

On Sun, Mar 23, 2008 at 3:46 PM, Alan W. Irwin wrote:
> 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}"
>  )

Hello Alan,

Sorry for the confusion. This change was made as a bug fix to resolve
a problem reported to the list. Can't remember the error that was
generated, but it was possibly to handle spaces in definitions (i.e.,
-DFOO="A space containing string") or some of the other variables. You
can see the patch applied at:
http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/FindwxWidgets.cmake?root=CMake&r1=1.7&r2=1.8

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

The problem is that it seems you are using (abusing?) the use of the
interface variables. That is, you are not using ADD_DEFINITIONS and
INCLUDE_DIRECTORIES, but building the compile flags directly?

Although I understand what you are pointing out, I'm not sure that
this is good in the sense that there is a maintainence overhead added.
In this particular case, I'm not sure that it would help since it was
a bug fix although it involves an interface variable which I believe
we should be backwards compatible with as much as possible. That is, I
do believe we should maintain backwards compatibility with variables
published as the modules interface, but I don't think we should be
backward compatible with variables meant to be used only internally
such as WX_core/WX_cored, which obviously was not the case in question
here.

That said, I do believe the find modules should have a process to
deprecate variables and evolve... I'm just not sure if we want an
independent release schedule.

Just my $.02...

--Miguel