I posted this a while ago but I haven't really been able to think of too many highly desired features that would motivate this upgrade.  Upon furthor though, I have come up with a few that I think are fairly motivating:

1.  New syntax available for add_test employing the use of generator expressions .  Right now most of the tests are specified as:

add_executable( MyTestDriver ${TEST_SOURCES} )
add_test( MyTestName ${EXECUTABLE_OUTPUT_PATH}/MyTestDriver --args --to --test )

The problem is that the EXECUTABLE_OUTPUT_PATH is the default output location for all executables but there's no requirement that the executable is actually there.  There's just an asssumption that the targewt will go into the default location.  Target properties could have been set that will place the executable somewhere else entirely.  The new syntax for add_test that can accommodate this uses "generator expressions".  The generator expressions allow cmake to resolve the actual output location of a target:

add_executable( MyTestDriver ${TEST_SOURCES} )
add_test( NAME MyTestName
          COMMAND $<TARGET_FILE:MyTestDriver> --args --to --test)

$<TARGET_FILE:MyTestDriver> will be resolved to the full path of the output executable.  This is known by cmake at build system generation time.  More can be read here: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_test

2.  The deprecation of EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH in favor of a new set of output locations: ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and RUNTIME_OUTPUT_DIRECTORY target properties.  More details can be found on the CMake 2.6 or 2.8 docs page but essentially this allows the the buuld system ti distinguish between runtime components and link time components.  So on windows, for instance, for a shared library, the DLL get placed in the RUNTIME_OUTPUT_DIRECTORY and the import library would be placed in the ARCHIVE_OUTPUT_DIRECTORY instead of them both getting placed in the library destination.  Currently VXL doesn't support shared libraries on Windows because it's missing all of the declspec(_dllexport) decorations but if there's ever a though of getting there then having this seperation is really nice to have.

3.  Amitha just raised another argument in respose to a different  thread:

"This macro is usually only defined for gcc, which allows const float
initializers as an extension even on C++98.  There is a try-compile
during configure time that tries to figure out if the compiler supports
it or not.  However, the test only looks for a successful exit from the
compiler (i.e., no errors), and so the test would not catch the warning.

Newer CMake versions have a way of doing try-compiles that parse the
output of the test case.  (I'm not sure exactly which version.)  If we
were willing to update the required version of CMake, we could update
the try-compile to fail if there are warnings or errors."

Thoughts?  Suggestions?  Comments?  Objections?

- Chuck

-- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos

On Sat, Sep 11, 2010 at 5:58 AM, Peter Vanroose <peter_vanroose@yahoo.co.uk> wrote:
CMake 2.6 has been out for more than 2 years now, and 2.8 is out, so I also don't see a reason why we should stick at 2.4.5.

On the other hand, as long as vxl does not use any new 2.6 features, it's maybe nice for CMake 2.4 users to know that they are still safe.

Two questions:
- Are there any "current" Linux distributions which still contain 2.4?
- Are there any 2.6 new features which vxl would benefit from?

--      Peter.