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