Re: orogen: Using PROJECT_SOURCE|BINARY_DIR instead of CMAKE_x_DIR

On Wed, Jun 12, 2013 at 8:42 AM, Leopold Palomo-Avellaneda
<[email protected]> wrote:
> A Dimecres, 12 de juny de 2013, Peter Soetens va escriure:
>> On Tue, Jun 11, 2013 at 11:57 PM, Leopold Palomo-Avellaneda
>> <[email protected]> wrote:
>> > A Dimarts, 11 de juny de 2013, Peter Soetens va escriure:
>> >> Hi,
>> >>
>> >> We're looking into chaining different packages into a single cmake
>> >> build, using catkin as the glue. There are two things to fix for doing
>> >> this:
>> >>
>> >> 1. never use CMAKE_SOURCE/BINARY_DIR but use the PROJECT_...
>> >> equivalent (refers to the closest project() statement)
>> >> 2. never define a target twice, both cmake targets as make targets,
>> >> for example, the 'regen' target.
>> >>
>> >> If we would:
>> >> 1. replace all these CMAKE_ occurences to PROJECT_...
>> >> 2. rename 'regen' to 'regen-${PROJECT_NAME}'
>> >>
>> >> Would we be fine or do I overlook something ? Would this break the
>> >> Rock workflow ?
>> >>
>> > this change will mean that orocos will depend to build on catkin?
>> >
>> > I would prefer that no ... please...
>>
>> No.. That's not how catkin works :) It's fully transparant and *no*
>> reference is made to any catkin code. The package is a plain CMake
>> package that can be integrated in a 'top level'/'master' catkin build.
>> It's just that the package must conform to some 'best practice' rules,
>> being the two ones I listed.
>
> Ok,
>
> probably I'm wrong or I didn't understand your mail. I just have the reference
> of ROS with _plain_ CMakeLists with:
>
> find_package(catkin)
> catkin_package()

We don't need this. This is for ROS users. We use:

find_package(OROCOS-RTT)

instead and don't require catkin_package() nor any other catkin macro/file.

>
> AFAIK catkin (from ros webpage) "catkin combines CMake macros and Python
> scripts to provide some functionality on top of CMake's normal workflow"

The whole discussion is actually independent of Catkin. It's not
Catkin requiring
these renames, it's cmake itself. If you want to build several
projects at once, cmake
can't handle name clashes.

>
> If I understand your propose, you are saying to use some vars with some name
> to after, compile it using some "macro catkin workspace, no?

No, I'm just fixing our cmake code.

>>
>> Catkin 'breaks' the independence of packages in the same package set:
>> they all need unique target names. Variable names don't clash, except
>> when cached afaikt. If there are clashes, they need to be fixed or
>> split up in two workspaces.
>
> Yes, but I'm a bit afraid about using this kind of tools. Simply, I would
> prefer not _need_ any ros code to build orocos.

You won't !

>
> Just my two ct.
>
> Leo

Peter
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev