2009/7/2 Adolfo Rodríguez <dofo79 [..] ...>:
> I was just taking a (nonexhaustive) look to the RTT cmake scripts for
> 2.0-mainline. Here's a couple of comments/questions:
>
> - Cache variables: RTT creates many cache variables, most of them being
> advanced configuration options. So my first suggestion would be to make
> (almost) all of them them advanced indeed.

I agree, the majority can be tagged as advanced.

> Also, I would make their naming a bit more uniform, especially the first
> part of the name. If you've used the cmake-gui app (a Qt-based alternative
> to ccmake), you'll notice that apart from the usual simple and advanced
> views, there is also the grouped view (i.e., a tree view), which can be
> reaaally convenient for projects with multiple dependencies. Grouping works
> for 2 or more variables whose name until the first underscore coincides. For
> RTT, the following prefixes exist (I might have missed one):
>
> OROBLD_*
> ORONUM_*
> OROPKG_*
> OROSEM_*
> ORO_*
> ENABLE_*
> CORBA_*
> OS_*
>
> It would be nice if they all shared a common prefix, be it ORO, OROCOS, RTT,
> or something else, so that they'll be nicely grouped together in cmake-gui.
> Special emphasis goes to the last three prefixes. They have way too general
> names and offer no hint to the package they belong to.

They only exist in our cmake build system, so they can only belong to
that package. Is see no reason to scope/prefix them, but I do agree on
the grouping.

>
>
> - Compatibility commands: I noticed that old cmake commands are used,
> especially when installing targets and files. The newer INSTALL command is
> encouraged. As the doc states
> "[The install] command supercedes the INSTALL_TARGETS command and the target
> properties PRE_INSTALL_SCRIPT and POST_INSTALL_SCRIPT. It also replaces the
> FILES forms of the INSTALL_FILES and INSTALL_PROGRAMS commands."

This has been fixed now, I didn't commit it yet because I was also
working on the Doxygen solution.

> - Commands and scripts with now standard equivalents:
>   - DependentOption.cmake: There now exists the CMAKE_DEPENDENT_OPTION
> command, that can be used instead of the macro provided by RTT. More info
> here
>
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:CMakeDependentO...

Is already gone from RTT, must be removed in OCL as well...

>
> - FindPkgConfig.cmake: There is now a standard module with the same name as
> the one provided by RTT. I've had name clashes with this in the past, and
> had to rename the file provided by RTT. If the functionality provided by the
> RTT script wants to be preserved, I would suggest renaming the file. more
> info here
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPkgConfig

OCL dependency detection still needs to be fleshed out.

>
>
>
> - Policy CMP0003: The root CMakeLists.txt contains the following lines:
>
> # for CMake 2.6 corrected behaviour (see "cmake --help-policy CMP0003")
> IF(COMMAND cmake_policy AND ${CMAKE_MAJOR_VERSION} EQUAL 2 AND
> ${CMAKE_MINOR_VERSION} GREATER 4)
>   CMAKE_POLICY(SET CMP0003 NEW)
> ENDIF(COMMAND cmake_policy AND ${CMAKE_MAJOR_VERSION} EQUAL 2 AND
> ${CMAKE_MINOR_VERSION} GREATER 4)
>
> are they really necessary? My guess would be that they're not, since we
> already require cmake>=2.6

I didn't dare to remove them yet. They are required if you mix -L and
absolute paths or something like that. That's no longer the case in
RTT, might still be in OCL...

Peter

...one more thing I forgot to ask. I didn't quite understand what is meant
by:

1.7 *Provide CMake macros for applications and components*

When users want to build Orocos components or applications, they require
flags and settings from the installed RTT and OCL libraries. A CMake macro
which gathers these flags for compiling an Orocos component or application
is provided. This is inspired on how ROS components are compiled.

Could someone please point me in the right direction?

TIA,

Adolfo

2009/7/2 Adolfo Rodríguez <dofo79 [..] ...>

> I was just taking a (nonexhaustive) look to the RTT cmake scripts for
> 2.0-mainline. Here's a couple of comments/questions:
>
> - Cache variables: RTT creates many cache variables, most of them being
> advanced configuration options. So my first suggestion would be to make
> (almost) all of them them advanced indeed.
> Also, I would make their naming a bit more uniform, especially the first
> part of the name. If you've used the cmake-gui app (a Qt-based alternative
> to ccmake), you'll notice that apart from the usual simple and advanced
> views, there is also the grouped view (i.e., a tree view), which can be
> reaaally convenient for projects with multiple dependencies. Grouping works
> for 2 or more variables whose name until the first underscore coincides. For
> RTT, the following prefixes exist (I might have missed one):
>
> OROBLD_*
> ORONUM_*
> OROPKG_*
> OROSEM_*
> ORO_*
> ENABLE_*
> CORBA_*
> OS_*
>
> It would be nice if they all shared a common prefix, be it ORO, OROCOS,
> RTT, or something else, so that they'll be nicely grouped together in
> cmake-gui. Special emphasis goes to the last three prefixes. They have way
> too general names and offer no hint to the package they belong to.
>
>
> - Compatibility commands: I noticed that old cmake commands are used,
> especially when installing targets and files. The newer INSTALL command is
> encouraged. As the doc states
> "[The install] command supercedes the INSTALL_TARGETS command and the
> target properties PRE_INSTALL_SCRIPT and POST_INSTALL_SCRIPT. It also
> replaces the FILES forms of the INSTALL_FILES and INSTALL_PROGRAMS
> commands."
>
> A complete list of "compatibility commands" can be found here:
>
>
> http://www.cmake.org/cmake/help/cmake2.6docs.html#section_Compatibility%...
>
>
> - Commands and scripts with now standard equivalents:
> - DependentOption.cmake: There now exists the CMAKE_DEPENDENT_OPTION
> command, that can be used instead of the macro provided by RTT. More info
> here
>
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:CMakeDependentO...
>
> - FindPkgConfig.cmake: There is now a standard module with the same name as
> the one provided by RTT. I've had name clashes with this in the past, and
> had to rename the file provided by RTT. If the functionality provided by the
> RTT script wants to be preserved, I would suggest renaming the file. more
> info here
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPkgConfig
>
>
>
> - Policy CMP0003: The root CMakeLists.txt contains the following lines:
>
> # for CMake 2.6 corrected behaviour (see "cmake --help-policy CMP0003")
> IF(COMMAND cmake_policy AND ${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
> CMAKE_POLICY(SET CMP0003 NEW)
> ENDIF(COMMAND cmake_policy AND ${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
>
> are they really necessary? My guess would be that they're not, since we
> already require cmake>=2.6
>
> That's it for now. Feedback welcome.
>
> Cheers,
>
> Adolfo
>
> --
> Adolfo Rodríguez Tsouroukdissian
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>