Re: orogen: Using PROJECT_SOURCE|BINARY_DIR instead of CMAKE_x_DIR

"Leopold Palomo-Avellaneda" <[email protected]>
Newsgroups gmane.science.robotics.orocos.devel
Message-ID <[email protected]>
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()

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

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

Just my two ct.

Leo

-- 
--
Leopold Palomo-Avellaneda <[email protected]>
Institut d'Organització i Control de Sistemes Industrials -IOC-
Universitat Politècnica de Catalunya -UPC-

Institute of Industrial and Control Engineering
Technical University of Catalonia
Avda. Diagonal 647, pl. 11
08028 BARCELONA (Spain)

Tel. +34-934017163
Fax. +34-934016605
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.