Re: [CMake] PLplot issues with the cvs version of CMake (wxwidgets)
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=CMaker1=1.7r2=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
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] PLplot issues with the cvs version of CMake (wxwidgets)
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=CMaker1=1.7r2=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 CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] PLplot issues with the cvs version of CMake (Fortran 95)
Hi Bill:
The Fortran 95 issue turned out to be that the default location for Fortran
95 modules has been moved from the top-level ${CMAKE_BINARY_DIR} to the more
logical subdirectory (in our case ${CMAKE_BINARY_DIR}/bindings/f95) where
the associated fortran library was created in the build tree. For PLplot
this required an INCLUDE_DIRECTORIES change (to build Fortran 95 examples
using the generated module files) as well as a change in build-tree location
for the generated Fortran modules that we install.
Since these changes are CMake version dependent, I used the following
command to distinguish the 2.4.x version from later versions:
if(CMAKE_CACHE_MAJOR_VERSION EQUAL 2 AND CMAKE_CACHE_MINOR_VERSION EQUAL 4)
This method appears to work (I get good results now for both the 2.4.8 and
cvs versions of CMake), but if there is a better way to distinguish CMake
versions from within cmake, please let me know.
Although this build-tree location change for the generated fortran modules
is a backwards incompatibility, I recommend you just accept that
incompatibility for your next release. Fortran support in 2.4.8 basically
sucks so I believe any CMake Fortran user would be happy to adopt a new
version with Fortran properly supported for the small expense of adjusting
for the backwards incompatibility created by adopting a much more logical
location for the generated module files.
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
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] PLplot issues with the cvs version of CMake (Fortran 95)
Alan W. Irwin wrote:
Hi Bill:
The Fortran 95 issue turned out to be that the default location for Fortran
95 modules has been moved from the top-level ${CMAKE_BINARY_DIR} to the
more
logical subdirectory (in our case ${CMAKE_BINARY_DIR}/bindings/f95) where
the associated fortran library was created in the build tree. For PLplot
this required an INCLUDE_DIRECTORIES change (to build Fortran 95 examples
using the generated module files) as well as a change in build-tree
location
for the generated Fortran modules that we install.
Since these changes are CMake version dependent, I used the following
command to distinguish the 2.4.x version from later versions:
if(CMAKE_CACHE_MAJOR_VERSION EQUAL 2 AND CMAKE_CACHE_MINOR_VERSION EQUAL 4)
This method appears to work (I get good results now for both the 2.4.8 and
cvs versions of CMake), but if there is a better way to distinguish CMake
versions from within cmake, please let me know.
CMAKE_MAJOR_VERSION and CMAKE_MINOR_VERSION should be set:
http://www.cmake.org/HTML/CMake-2.5.html#command_CMAKE_MAJOR_VERSION
http://www.cmake.org/HTML/CMake-2.5.html#command_CMAKE_MINOR_VERSION
Although this build-tree location change for the generated fortran modules
is a backwards incompatibility, I recommend you just accept that
incompatibility for your next release. Fortran support in 2.4.8 basically
sucks so I believe any CMake Fortran user would be happy to adopt a new
version with Fortran properly supported for the small expense of adjusting
for the backwards incompatibility created by adopting a much more logical
location for the generated module files.
Where did the modules go in 2.4.8?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] PLplot issues with the cvs version of CMake (wxwidgets)
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=CMaker1=1.7r2=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 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] PLplot issues with the cvs version of CMake (Fortran 95)
On 2008-03-23 20:57-0400 Bill Hoffman wrote: if(CMAKE_CACHE_MAJOR_VERSION EQUAL 2 AND CMAKE_CACHE_MINOR_VERSION EQUAL 4) CMAKE_MAJOR_VERSION and CMAKE_MINOR_VERSION should be set: Thanks for that reminder. I have now made the change and those variables work fine (without confusing issues with possible cache inconsistencies). Although this build-tree location change for the generated fortran modules is a backwards incompatibility, I recommend you just accept that incompatibility for your next release. Fortran support in 2.4.8 basically sucks so I believe any CMake Fortran user would be happy to adopt a new version with Fortran properly supported for the small expense of adjusting for the backwards incompatibility created by adopting a much more logical location for the generated module files. Where did the modules go in 2.4.8? top-level build tree which is not a logical location and the subject of a wish-list bug report IIRC. That location should not be propagated. The cmake cvs location of the subdirectory in the build tree where the associated library is built is a much more logical location. 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 CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
