New cmake macros for Orocos applications

On Monday 11 October 2010 11:54:31 Peter Soetens wrote:
> One of the problems newcomers have is to create and compile a component
> from scratch in 5 minutes. An (introduced to) orogen user will succeed in
> this, but I was looking for a solution for people that first want to play
> with the code.
>
> The idea is to have a tool that works like this:
>
> $ orocreate-pkg myrobot
> $ ls myrobot
> CMakeLists.txt
> manifest.xml
> myrobot.cpp
> myrobot-types.hpp
> orocos-myrobot.pc.in
> typekit/
>
> which generates a CMakelists.txt, manifest.xml, .pc file and some other
> dumb template code. It will rely on typegen to generate the transport
> c++/cmake code (in the typekit dir). The main actor here is the
> UseOrocos.cmake file that defines all the utility macros you can use in
> this new package.
>
> All components in the toolchain or outside should rely on these macro's
> too, when they're hand-written (ie outside of orogen).
>
> The UseOrocos.cmake file is installed with the RTT's find macros. I was
> wondering where the orocreate-pkg tool should best live: in a new
> repository under the orocos-toolchain, within RTT or with orogen ?
>
> Thoughts ?
>

If it supplies duplicate functionality wrt orogen I would not put it in
orogen. I would put it in OCL, to not pollute RTT, and IMHO it belongs there.

Ruben
> Peter

New cmake macros for Orocos applications

On Monday 11 October 2010 12:04:36 Ruben Smits wrote:
> On Monday 11 October 2010 11:54:31 Peter Soetens wrote:
> > One of the problems newcomers have is to create and compile a component
> > from scratch in 5 minutes. An (introduced to) orogen user will succeed in
> > this, but I was looking for a solution for people that first want to play
> > with the code.
> >
> > The idea is to have a tool that works like this:
> >
> > $ orocreate-pkg myrobot
> > $ ls myrobot
> > CMakeLists.txt
> > manifest.xml
> > myrobot.cpp
> > myrobot-types.hpp
> > orocos-myrobot.pc.in
> > typekit/
> >
> > which generates a CMakelists.txt, manifest.xml, .pc file and some other
> > dumb template code. It will rely on typegen to generate the transport
> > c++/cmake code (in the typekit dir). The main actor here is the
> > UseOrocos.cmake file that defines all the utility macros you can use in
> > this new package.
> >
> > All components in the toolchain or outside should rely on these macro's
> > too, when they're hand-written (ie outside of orogen).
> >
> > The UseOrocos.cmake file is installed with the RTT's find macros. I was
> > wondering where the orocreate-pkg tool should best live: in a new
> > repository under the orocos-toolchain, within RTT or with orogen ?
> >
> > Thoughts ?
>
> If it supplies duplicate functionality wrt orogen I would not put it in
> orogen. I would put it in OCL, to not pollute RTT, and IMHO it belongs
> there.

The tool depends mainly on RTT (UseOrocos.cmake and rtt headers) and only on
one file of OCL ("ocl/Component.hpp"). Since OCL's Component.hpp also only
depends on RTT (it doesn't have a .cpp file, it's header only), we're back to
the question if Component.hpp belongs in OCL in the first place.

I'll dump it in OCL for now, because of that dependency, but it still itches.

Peter

New cmake macros for Orocos applications

On Oct 13, 2010, at 04:28 , Peter Soetens wrote:

> On Monday 11 October 2010 12:04:36 Ruben Smits wrote:
>> On Monday 11 October 2010 11:54:31 Peter Soetens wrote:
>>> One of the problems newcomers have is to create and compile a component
>>> from scratch in 5 minutes. An (introduced to) orogen user will succeed in
>>> this, but I was looking for a solution for people that first want to play
>>> with the code.
>>>
>>> The idea is to have a tool that works like this:
>>>
>>> $ orocreate-pkg myrobot
>>> $ ls myrobot
>>> CMakeLists.txt
>>> manifest.xml
>>> myrobot.cpp
>>> myrobot-types.hpp
>>> orocos-myrobot.pc.in
>>> typekit/
>>>
>>> which generates a CMakelists.txt, manifest.xml, .pc file and some other
>>> dumb template code. It will rely on typegen to generate the transport
>>> c++/cmake code (in the typekit dir). The main actor here is the
>>> UseOrocos.cmake file that defines all the utility macros you can use in
>>> this new package.
>>>
>>> All components in the toolchain or outside should rely on these macro's
>>> too, when they're hand-written (ie outside of orogen).
>>>
>>> The UseOrocos.cmake file is installed with the RTT's find macros. I was
>>> wondering where the orocreate-pkg tool should best live: in a new
>>> repository under the orocos-toolchain, within RTT or with orogen ?
>>>
>>> Thoughts ?
>>
>> If it supplies duplicate functionality wrt orogen I would not put it in
>> orogen. I would put it in OCL, to not pollute RTT, and IMHO it belongs
>> there.
>
> The tool depends mainly on RTT (UseOrocos.cmake and rtt headers) and only on
> one file of OCL ("ocl/Component.hpp"). Since OCL's Component.hpp also only
> depends on RTT (it doesn't have a .cpp file, it's header only), we're back to
> the question if Component.hpp belongs in OCL in the first place.
>
> I'll dump it in OCL for now, because of that dependency, but it still itches.

+1, but practicality wins sometimes too ...

Is this a first implementation of the CMake "application macros" that we discussed in Barcelona?

Is this something that OCL could use to work with RTT, instead of more custom CMake logic?
S

New cmake macros for Orocos applications

On Thu, Oct 14, 2010 at 2:32 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Oct 13, 2010, at 04:28 , Peter Soetens wrote:
>
>> On Monday 11 October 2010 12:04:36 Ruben Smits wrote:
>>> On Monday 11 October 2010 11:54:31 Peter Soetens wrote:
>>>> One of the problems newcomers have is to create and compile a component
>>>> from scratch in 5 minutes. An (introduced to) orogen user will succeed in
>>>> this, but I was looking for a solution for people that first want to play
>>>> with the code.
>>>>
>>>> The idea is to have a tool that works like this:
>>>>
>>>> $ orocreate-pkg myrobot
>>>> $ ls myrobot
>>>> CMakeLists.txt
>>>> manifest.xml
>>>> myrobot.cpp
>>>> myrobot-types.hpp
>>>> orocos-myrobot.pc.in
>>>> typekit/
>>>>
>>>> which generates a CMakelists.txt, manifest.xml, .pc file and some other
>>>> dumb template code. It will rely on typegen to generate the transport
>>>> c++/cmake code (in the typekit dir). The main actor here is the
>>>> UseOrocos.cmake file that defines all the utility macros you can use in
>>>> this new package.
>>>>
>>>> All components in the toolchain or outside should rely on these macro's
>>>> too, when they're hand-written (ie outside of orogen).
>>>>
>>>> The UseOrocos.cmake file is installed with the RTT's find macros. I was
>>>> wondering where the orocreate-pkg tool should best live: in a new
>>>> repository under the orocos-toolchain, within RTT or with orogen ?
>>>>
>>>> Thoughts ?
>>>
>>> If it supplies duplicate functionality wrt orogen I would not put it in
>>> orogen. I would put it in OCL, to not pollute RTT, and IMHO it belongs
>>> there.
>>
>> The tool depends mainly on RTT (UseOrocos.cmake and rtt headers) and only on
>> one file of OCL ("ocl/Component.hpp"). Since OCL's Component.hpp also only
>> depends on RTT (it doesn't have a .cpp file, it's header only), we're back to
>> the question if Component.hpp belongs in OCL in the first place.
>>
>> I'll dump it in OCL for now, because of that dependency, but it still itches.
>
> +1, but practicality wins sometimes too ...
>
> Is this a first implementation of the CMake "application macros" that we discussed in Barcelona?

Yes. The biggest preparation was done by Adolfo BTW, which had set a
clean stage to start from.

>
> Is this something that OCL could use to work with RTT, instead of more custom CMake logic?

Yes. All (hand written) components, including ocl's should use these macros.

Peter

New cmake macros for Orocos applications

On 10/14/2010 04:59 PM, Peter Soetens wrote:
>
>> Is this something that OCL could use to work with RTT, instead of more custom CMake logic?
> Yes. All (hand written) components, including ocl's should use these macros.
If some brave soul would like to clean out the cmake logic in
orogen-generated components (by moving it to these files), I would not
mind either ...