Support configuring executables for Orocos

The Orocos UseOROCOS-rtt.cmake macros force an executable/library naming convention and force installation of the final product. IMHO it is not the responsibility of middleware to make such system-level policy decisions. The Orocos macros also do not easily support certain types of application unit tests.

I propose the following changes and have submitted PR #55 which implements a preliminary version of this

- the essence is supporting configuring executables with an Orocos macro (orocos_configure_executable), rather than configuring, naming, adding to cmake, and installing, such executables in one Orocos macro (e.g. orocos_executable).
- this allows the application to create an application or test as it sees fit, and simply adds the necessary CMake items to that executable to have it link and run with Orocos
- this fix does not change any existing behaviour
- future work would refactor the macros to have the existing orocos_exectuable() macros call the orocos_configure_exectuable() macro internally, to remove duplication
- future work would add a orocos_configure_library() macro, to support configuring libraries (e.g. not all libraries need to be installed).
- NB there is a TODO in the orocos_configure_executable macro, as I’m not sure what to do about rosbuild calls in there.

The net effect is that instead of an application doing this

orocos_executable(myexec a.cpp …)

the application can instead *choose* to do

add_executable(myexec a.cpp …)
orocos_configure_executable(myexec)

or

add_executable(myexec a.cpp …)
add_test(my exec)
orocos_configure_executable(myexec)

Thoughts?
Stephen

Support configuring executables for Orocos

2014-08-18 12:52 GMT+02:00 S Roderick <kiwi [dot] net [..] ...>:

> The Orocos *UseOROCOS-rtt.cmake* macros force an executable/library
> naming convention and force installation of the final product. IMHO it is
> not the responsibility of middleware to make such system-level policy
> decisions. The Orocos macros also do not easily support certain types of
> application unit tests.
>

+1 !

>
> I propose the following changes and have submitted PR #55 which implements
> a preliminary version of this
>
> - the essence is supporting *configuring* executables with an Orocos
> macro (*orocos_configure_executable*), rather than *configuring, naming,
> adding to cmake, *and* installing, *such executables in one Orocos macro
> (e.g. *orocos_executable*).
> - this allows the application to create an application or test as it sees
> fit, and simply adds the necessary CMake items to that executable to have
> it link and run with Orocos
> - this fix does not change any existing behaviour
> - future work would refactor the macros to have the existing
> *orocos_exectuable()* macros call the *orocos_configure_exectuable() *macro
> internally, to remove duplication
> - future work would add a *orocos_configure_library()* macro, to support
> configuring libraries (e.g. not all libraries need to be installed).
> - NB there is a TODO in the *orocos_configure_executable *macro, as I’m
> not sure what to do about rosbuild calls in there.
>
> The net effect is that instead of an application doing this
>
> * orocos_executable(myexec a.cpp …)*
>
> the application can instead *choose* to do
>
> * add_executable(myexec a.cpp …)*
> * orocos_configure_executable(myexec)*
>
> or
>
> * add_executable(myexec a.cpp …)*
> * add_test(my exec)*
> * orocos_configure_executable(myexec)*
>
> Thoughts?
> Stephen
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>