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