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