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

[Bill Hoffman]

Alan W. Irwin wrote:
> On 2008-03-23 16:58-0400 Miguel A. Figueroa-Villanueva wrote:
> 
>> On Sun, Mar 23, 2008 at 3:46 PM, Alan W. Irwin wrote:
>>>  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.
> 
>> 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 
>>
>>
> 
> Yes, it appears to be a classic case of it being impossible to address one
> important issue without creating a backwards incompatibility.
> 
>>
>> 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?
> 
> Yes.  The problem with INCLUDE_DIRECTORIES (and ADD_DEFINITIONS?) is they
> apply to everything built in that directory.  I far prefer to use explicit
> compile flags for each shared object I am building in that directory.
> 
>>>  [out of order for clarity] 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.
> 
>>
>> 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.
> 
> It would be some extra work to set this up for the first time, but if
> automated properly, I don't think there would be a lot of on-going work 
> once
> this was set up.
> 
>> [...]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...
> 
> I agree with the general goal of allowing the modules to evolve in a
> reasonable way (such as the change you made) so long as we provide some
> mechanism to assure backwards compatibility.  My understanding of how Bill
> currently handles this issue is he is ultra-cautious about making any
> changes to modules _that are released_.  In practice this may mean your
> greatly improved FindwxWidgets.cmake in cvs will not get into the next
> release because of the above demonstrated backwards incompatibility.  That
> would be a real shame, and I would like to find some other method of
> freezing the modules such as providing easy access to previous module
> releases.  I don't care about the details so long as something is done 
> about
> this issue other than the current virtual freeze on module changes that are
> allowed to get into releases.
> 

I don't like to put major changes in modules into patch releases. We are 
now working on a major release 2.6, so I am putting in all module 
changes.  I don't see how having a separate release track for modules 
would help things.  It would require two separate downloads for CMake? 
The number one objection to adopting CMake is having to install CMake 
before being able to build a project.  I don't want to make that 
download any more complicated.  If someone wants a fix in a module, it 
is very easy to copy the module into the project and override the one in 
CMake.

I will have to look into this space vs. ; separation issue.  I do think 
plplot is abusing things a bit, and should not be constructing -I stuff, 
as it may not be portable to IDE's and other compilers in the future. 
Some compiler may not even know what -I is.  CMake is supposed to hide 
low level things like that from the user.  I am aware of the issue with 
target vs. directory level includes and defines, and at some point it 
will get fixed with a target property.   For now, I would recommend that 
projects use the directory level includes and defines if at all possible 
as it will be much more portable.

I am thinking that maybe I can add some checks into the wx stuff to look 
for spaces in the define list, and only then separate with ;.  This can 
not break any project because it will still be space separated unless 
there is something with a space.  The something with a space would have 
been broken anyway, and no project could have depended on it working 
that way.

-Bill