Re: orogen: Using PROJECT_SOURCE|BINARY_DIR instead of CMAKE_x_DIR

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.

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.

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