CMake 2.4.4 available for download

[Alan W. Irwin]

On 2006-11-21 10:57-0500 Bill Hoffman wrote:

> On behalf of myself, Ken, Brad, Andy and the rest of the CMake team, we are
> pleased to announce that CMake 2.4.4 is available for download at:
> http://www.cmake.org/HTML/Download.html
> If you have any problems or find any bugs, please report them at 
> www.cmake.org/Bug.
> A list of changes for the 2.4 release tree is included below.

CMake built cleanly (using the bootstrap script to start) on my Debian
stable and Ubuntu Dapper systems.  However, there were errors (certain
necessary scripts were silently not created) when I attempted to build
PLplot with the new version of CMake.

I suspect this is a bug in CMake-2.4.4, but I am not sure. Anyhow, here is
the issue in more detail.

We build example executables in our examples/c++ directory called x01, x02,
etc.  We build scripts in examples/python and examples/tcl using custom
commands with

OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/x01

etc., and then create a custom_target (e.g., python_examples in the
examples/python directory) which depends on the various x??
scripts that are being built.  Note, the DEPENDS uses the full name:
${CMAKE_CURRENT_BINARY_DIR}/x01

This worked fine in 2.4.3, but for 2.4.4 there is a clash between the script
OUTPUT file names in examples/python and examples/tcl and the targets of the
same name in examples/c++.  For example, in the build tree I get this
incorrect result:

software at chickadee> grep x01 \
examples/python/CMakeFiles/python_examples.dir/build.make
examples/python/CMakeFiles/python_examples: examples/c++/x01

Because of this incorrect dependency, the result is the custom command to
generate the script file x01 in examples/python is never saved in the
Makefile (as far as I can tell), and is certainly never executed.

In other words, python_examples is incorrectly depending on the executable
built in the c++ tree even though there is no explicit mention of that
executable and the file DEPENDS are done with e.g.,
${CMAKE_CURRENT_BINARY_DIR}/x01.

The workaround for the issue is not too bad.  You simply use a different
target name for the add_executable commands in examples/c++/CMakeLists.txt,
e.g., disambiguate_x01, then use set_target_properties OUTPUT_NAME x01 to
create the executable in examples/c++ of the same name as before.  Then the
examples/python and examples/tcl scripts get created as for 2.4.3, and
everything else seems to be fine.

In sum, targets which are assigned the same target name as the filename part
of the path+filename in OUTPUT (in add_custom_command) and DEPENDS (in
add_custom_target) are messing up those file depends in 2.4.4. I strongly
suspect this is a newly introduced bug, but I am not completely sure of
this.

We do have a workaround for this issue, and 2.4.4 solves some of the bugs we
had to workaround for 2.4.3 so PLplot will use 2.4.4 from now on (unless
some showstopper shows up on non-Linux platforms).

My thanks to the CMake developers for all their hard work for this release.

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 Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________