CMake and finding external dependencies (from Omniorb merge vs OS-X port)

Submitted by Adolfo Rodríguez on Mon, 2009-02-09 10:30

RTT-dev

Hi all,

Inspired by the recent posts made by Sylvain and Stephen,

Quote:

I'd feel much better if each external dependency would have its own Find*.cmake script instead of the generic overly complex check_* script.

Finally, there is more complete (and tested) scripts for dependencies like boost, maybe we should use it.

I'd like to further discuss the subject, and poll for opinions. I believe that for us, correctly finding the external dependencies is one of the more painful parts of the build, especially because we have some of the dependencies in nonstandard locations. So here go the comments:

- Each external dependency should have its own FindXXX module (modularity!), and whenever possible, existing modules should be used. The Cmake guys already support (and maintain!) a large number of packages, and many more can be found elsewhere in the sources of other projects. The FindBoost script is a great example of this: it is actively maintained, and has been recently endowed with very nice functionalities (minimum required version, required components, use static, use multithreading...). OTOH, the Orocos script is quite simple, and is not the same in RTT and KDL!.

- When writing our own FindXXX.cmake scripts, what would be your preferred policy for finding headers/libs/programs?
- Search in user-defined paths, then system paths e.g., using the HINTS keyword (Cmake >=2.6.1)

- Search ONLY user-defined paths e.g., using PATHS + NO_DEFAULT_PATH
- A third way?
We currently use a variable called XXX_USE (a la Boost_USE) to specify a path prefix that can be used with any of the above policies.

- Could it be possible to require a minimum CMake version higher than 2.2?, or such backwards compatibility is crucial for the Orocos project?. Many great functionalities have been added to CMake since the 2.2 era, in particular in the 2.6x releases. For example, the DEPENDENT_OPTION custom macro is already supported as CMAKE_DEPENDENT_OPTION, and the FindPkgConfig pkg-config module looks pretty complete.

If there's interest, I'm offering to help in these areas, but first of all I would like to know what are your thoughts on the matter, what would be good to improve, what are the missing features, and what are the already implemented features that are better than other existing alternatives (and thus should be preserved!).

Looking forward to read your comments (developpers and users)

Best,

Adolfo Rodríguez Tsouroukdissian

Robotics engineer
PAL ROBOTICS S.L

http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by snrkiwi on Mon, 2009-02-09 14:30.

On Feb 9, 2009, at 05:19 , Adolfo Rodríguez wrote:

<blockquote type="cite">Hi all,

Inspired by the recent posts made by Sylvain and Stephen,

Quote:

I'd feel much better if each external dependency would have its own Find*.cmake script instead of the generic overly complex check_* script.
Finally, there is more complete (and tested) scripts for dependencies like boost, maybe we should use it.

It's also the interconnected nature of the dependancies, within check_depend and global_setup, that makes life difficult. That's something we as Orocos users/developers have to deal with. The FindXXX modules will only clean up some of this complexity, not all.

<blockquote type="cite">- Each external dependency should have its own FindXXX module (modularity!), and whenever possible, existing modules should be used. The Cmake guys already support (and maintain!) a large number of packages, and many more can be found elsewhere in the sources of other projects. The FindBoost script is a great example of this: it is actively maintained, and has been recently endowed with very nice functionalities (minimum required version, required components, use static, use multithreading...). OTOH, the Orocos script is quite simple, and is not the same in RTT and KDL!.

- When writing our own FindXXX.cmake scripts, what would be your preferred policy for finding headers/libs/programs?
- Search in user-defined paths, then system paths e.g., using the HINTS keyword (Cmake >=2.6.1)<blockquote>

Possibly I would argue for this, in the CMake recommended fashion

FIND_FILE(... NO_DEFAULT_PATH)

FIND_FILE(...) ** not done if the above finds it

We currently use the above in only one place in RTT, and IIRC it was due to a MacPorts + Mac OS X install. Otherwise, a single FIND_FILE() currently works for all our dependancies.

<blockquote type="cite"> - Search ONLY user-defined paths e.g., using PATHS + NO_DEFAULT_PATH<blockquote>

I disagree with this one. Default OS installs will only have things in system paths. We must use those for searching.

<blockquote type="cite"> - A third way?
We currently use a variable called XXX_USE (a la Boost_USE) to specify a path prefix that can be used with any of the above policies.

- Could it be possible to require a minimum CMake version higher than 2.2?, or such backwards compatibility is crucial for the Orocos project?. Many great functionalities have been added to CMake since the 2.2 era, in particular in the 2.6x releases. For example, the DEPENDENT_OPTION custom macro is already supported as CMAKE_DEPENDENT_OPTION, and the FindPkgConfig pkg-config module looks pretty complete.

If there's interest, I'm offering to help in these areas, but first of all I would like to know what are your thoughts on the matter, what would be good to improve, what are the missing features, and what are the already implemented features that are better than other existing alternatives (and thus should be preserved!).

Looking forward to read your comments (developpers and users)<blockquote>

Ditto.

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by Sylvain Joyeux on Mon, 2009-02-16 11:35.

On Monday 09 February 2009 14:27:29 S Roderick wrote:
> On Feb 9, 2009, at 05:19 , Adolfo Rodríguez wrote:
> > Hi all,
> >
> > Inspired by the recent posts made by Sylvain and Stephen,
> >
> >

Quote:

> > I'd feel much better if each external dependency would have its own
> > Find*.cmake script instead of the generic overly complex check_*
> > script.
> > Finally, there is more complete (and tested) scripts for
> > dependencies like boost, maybe we should use it.
> >

> >
> > I'd like to further discuss the subject, and poll for opinions. I
> > believe that for us, correctly finding the external dependencies is
> > one of the more painful parts of the build, especially because we
> > have some of the dependencies in nonstandard locations. So here go
> > the comments:
>
> It's also the interconnected nature of the dependancies, within
> check_depend and global_setup, that makes life difficult. That's
> something we as Orocos users/developers have to deal with. The FindXXX
> modules will only clean up some of this complexity, not all.
Not true. Each Find* script should search for its needed dependencies. If Foo
needs Bar *and* Blah needs Bar as well, then Bar should be checked in both
FindFoo and FindBlah. *Then*, per CMake recommendations, FindBlah should check
if Blah_FOUND is there and not check it again.

Moreover, the Blah_CFLAGS, Blah_LIBRARIES and friends should *only* contain
flags that are meaningful to *use* the said library. My point is that
accumulating a lof of stuff in global variables (like it is done today) is bad,
because we don't know what is happening. What should be is:
* each FindBlah script sets the variables needed to use Blah
* each user of Blah do two things:
- use the necessary variables for its own compilation/link
- set up its own _CFLAGS, _LIBRARIES and friends properly. In general,
very few flags coming from the dependencies should be propagated.

The only issue remaining is for versioning (if the first FIND_PACKAGE requires
a version that is different from the second FIND_PACKAGE, then you can have a
problem with ignoring the Find script when Foo_FOUND is set).

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by Adolfo Rodríguez on Mon, 2009-02-09 14:55.

On Mon, Feb 9, 2009 at 2:27 PM, S Roderick <kiwi.net@mac.com> wrote:
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Feb 9, 2009, at 05:19 , Adolfo Rodríguez wrote:

<blockquote type="cite">Hi all,

Inspired by the recent posts made by Sylvain and Stephen,

Quote:

I have seen those files but don't quite understand what you mean by interconnected nature of the dependencies. Could you develop a little bit more the idea? Do you mean things like "if corba found do this, else do that"

Possibly I would argue for this, in the CMake recommended fashion

FIND_FILE(... NO_DEFAULT_PATH)

FIND_FILE(...) ** not done if the above finds it

I currently do this with one single command, using the HINTS keyword I mention above, but is only supported in CMake 2.6.1 and later:
FIND_FILE(... HINTS /path/to/hints PATH /other/paths)

What CMake does is to search in HINTS before PATH and the system directories. The complete search process is detailed here. This of course brings in the discussion the topic of supporting (or not) a more recent minimum CMake version.

We currently use the above in only one place in RTT, and IIRC it was due to a MacPorts + Mac OS X install. Otherwise, a single FIND_FILE() currently works for all our dependancies.

<blockquote type="cite"> - Search ONLY user-defined paths e.g., using PATHS + NO_DEFAULT_PATH<blockquote>

I disagree with this one. Default OS installs will only have things in system paths. We must use those for searching.

Same here, just wanted to have all bases covered.

Ditto.

--
Adolfo Rodríguez Tsouroukdissian

Robotics engineer

PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by sspr on Mon, 2009-02-09 22:05.

delivered to the orocos-dev mailing list, although I added Adolfo's gmail
address. Adolfo, are you posting to the forum or to the mailing list directly
? )

On Monday 09 February 2009 15:53:47 Adolfo Rodríguez wrote:
> On Mon, Feb 9, 2009 at 2:27 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> > On Feb 9, 2009, at 05:19 , Adolfo Rodríguez wrote:
> >
> > Hi all,
> >
> > Inspired by the recent posts made by Sylvain and Stephen,
> >
> >

Quote:

> > I'd feel much better if each external dependency would have its own
> > Find*.cmake script instead of the generic overly complex check_* script.
> > Finally, there is more complete (and tested) scripts for dependencies
> > like boost, maybe we should use it.
> >

> >
> > I'd like to further discuss the subject, and poll for opinions. I believe
> > that for us, correctly finding the external dependencies is one of the
> > more painful parts of the build, especially because we have some of the
> > dependencies in nonstandard locations. So here go the comments:
> >
> >
> > It's also the interconnected nature of the dependancies, within
> > check_depend and global_setup, that makes life difficult. That's
> > something we as Orocos users/developers have to deal with. The FindXXX
> > modules will only clean up some of this complexity, not all.
>
> I have seen those files but don't quite understand what you mean by
> interconnected nature of the dependencies. Could you develop a little bit
> more the idea? Do you mean things like "if corba found do this, else do
> that"
>
> > - Each external dependency should have its own FindXXX module
> > (modularity!), and whenever possible, existing modules should be used.
> > The Cmake guys already support (and maintain!) a large number of
> > packages, and many more can be found elsewhere in the sources of other
> > projects. The
> > FindBoost<http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindBo
> >ost>script is a great example of this: it is actively maintained, and has
> > been recently endowed with very nice functionalities (minimum required
> > version, required components, use static, use multithreading...). OTOH,
> > the Orocos script is quite simple, and is not the same in RTT and KDL!.
> >
> > - When writing our own FindXXX.cmake scripts, what would be your
> > preferred policy for finding headers/libs/programs?
> > - Search in user-defined paths, then system paths e.g., using the HINTS
> > keyword (Cmake >=2.6.1)
> >
> >
> > Possibly I would argue for this, in the CMake recommended fashion
> >
> > FIND_FILE(... NO_DEFAULT_PATH)
> > FIND_FILE(...) ** not done if the above finds it
>
> I currently do this with one single command, using the HINTS keyword I
> mention above, but is only supported in CMake 2.6.1 and later:
> FIND_FILE(... HINTS /path/to/hints PATH /other/paths)
> What CMake does is to search in HINTS before PATH and the system
> directories. The complete search process is detailed
> here<http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_file>.
> This of course brings in the discussion the topic of supporting (or not) a
> more recent minimum CMake version.

I would love to have everyone use 2.6, but I think 2.4 is more reasonable,
until Lenny is out :-)

Before you take a close look at the CMake logic, checkout SVN trunk, because
some changes were already done by other people. RTT should today about work
with non-standard installs. Just set CMAKE_INCLUDE_PATH correctly.

I'm not going to invest time coding this. Any patches for the build system
will most likely be accepted, but realise that buildsystem changes always take
more time than you estimate, mainly because everything operates in a 'global
space'.

Peter
--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by fosini on Mon, 2009-03-02 17:10.

Hi all,

I've been checking out the RTT 1.8 CMakeLists scripts, in particular where
the external dependencies are found, and I still believe that some
improvements can be done.
First of all, I've noticed something that I don't quite understand, and
wanted to ask what is the rationale behind it: Header file and library
include paths are sometimes specified using the usual cmake commands
include_directories() and link_directories(), respectively; and other times
by explicitly setting -I and -L flags. The same happens when linking against
a library, sometimes the now deprecated [1] link_libraries() command is
used, and other times by explicitly setting -l flags.
I would suggest that, if possible, cmake commands should be used for this.
This would alleviate some of the accumulated flags (Stephen: are these
_some_ of the flags you were referring to?).

Secondly, I've been thinking about the policy for specifying where to look
for headers, libraries, and programs. What I would like the most is a
default behavior that searches according to the usual CMake process, with
the possibility of overriding it for unusual cases. One not-so-uncommon
example would be to have multiple versions of a library installed in the
same machine (a stable one in the system path, and an experimental one
somewhere else). A recent article on the CMake wiki [2], suggests using an
environment variable for this (I believe I've seen this approach somewhere
in RTT or OCL). I've written a test FindXerces.cmake based on this idea and
those posted here [3]. Two files are attached to this post:
- FindXerces.cmake -> Actual script for finding the Xerces XML parser
- LibFindMacros.cmake -> A (slightly) modified version of a script available
in [3] (Only added extra output messages)

Very brief example usage. If target foo depends on Xerces, then:

find_package(Xerces REQUIRED) # REQUIRED and QUIET parameters are optional
add_library(foo bar.cpp)
inlcude_directories(${Xerces_INCLUDE_DIRS})
target_link_libraries(foo ${Xerces_LIBRARIES})

If Xerces is installed in an unusual location, the Xerces_ROOT env. variable
can be defined with the path to its location.

Volunteers are welcome to take a look at the files, test them, and be critic
about them. If we arrive to a consensus on this matter, I could work on my
(not so abundant ;) ) spare time and prepare modules for those dependencies
that do not have an existing Find* module. I believe that the minimum
required CMake version for them to work is 2.4, but hey, lenny's out, and
comes with 2.6.0 :-).

Cheers,

Adolfo

[1] target_link_libraries should be used instead, see
http://www.cmake.org/cmake/help/cmake2.6docs.html#command:link_libraries
[2] http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules
[3] http://cmake.org/Wiki/CMake:How_To_Find_Libraries

On Mon, Feb 9, 2009 at 11:00 PM, Peter Soetens <peter [dot] soetens [..] ...>wrote:

> (note: there's something strange going on with this thread, parts are not
> delivered to the orocos-dev mailing list, although I added Adolfo's gmail
> address. Adolfo, are you posting to the forum or to the mailing list
> directly
> ? )
>
> On Monday 09 February 2009 15:53:47 Adolfo Rodríguez wrote:
> > On Mon, Feb 9, 2009 at 2:27 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> > > On Feb 9, 2009, at 05:19 , Adolfo Rodríguez wrote:
> > >
> > > Hi all,
> > >
> > > Inspired by the recent posts made by Sylvain and Stephen,
> > >
> > >

Quote:

> > > I'd feel much better if each external dependency would have its own
> > > Find*.cmake script instead of the generic overly complex check_*
> script.
> > > Finally, there is more complete (and tested) scripts for dependencies
> > > like boost, maybe we should use it.
> > >

> > >
> > > I'd like to further discuss the subject, and poll for opinions. I
> believe
> > > that for us, correctly finding the external dependencies is one of the
> > > more painful parts of the build, especially because we have some of the
> > > dependencies in nonstandard locations. So here go the comments:
> > >
> > >
> > > It's also the interconnected nature of the dependancies, within
> > > check_depend and global_setup, that makes life difficult. That's
> > > something we as Orocos users/developers have to deal with. The FindXXX
> > > modules will only clean up some of this complexity, not all.
> >
> > I have seen those files but don't quite understand what you mean by
> > interconnected nature of the dependencies. Could you develop a little bit
> > more the idea? Do you mean things like "if corba found do this, else do
> > that"
> >
> > > - Each external dependency should have its own FindXXX module
> > > (modularity!), and whenever possible, existing modules should be used.
> > > The Cmake guys already support (and maintain!) a large number of
> > > packages, and many more can be found elsewhere in the sources of other
> > > projects. The
> > > FindBoost<
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindBo
> > >ost>script is a great example of this: it is actively maintained, and
> has
> > > been recently endowed with very nice functionalities (minimum required
> > > version, required components, use static, use multithreading...). OTOH,
> > > the Orocos script is quite simple, and is not the same in RTT and KDL!.
> > >
> > > - When writing our own FindXXX.cmake scripts, what would be your
> > > preferred policy for finding headers/libs/programs?
> > > - Search in user-defined paths, then system paths e.g., using the
> HINTS
> > > keyword (Cmake >=2.6.1)
> > >
> > >
> > > Possibly I would argue for this, in the CMake recommended fashion
> > >
> > > FIND_FILE(... NO_DEFAULT_PATH)
> > > FIND_FILE(...) ** not done if the above finds it
> >
> > I currently do this with one single command, using the HINTS keyword I
> > mention above, but is only supported in CMake 2.6.1 and later:
> > FIND_FILE(... HINTS /path/to/hints PATH /other/paths)
> > What CMake does is to search in HINTS before PATH and the system
> > directories. The complete search process is detailed
> > here<http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_file
> >.
> > This of course brings in the discussion the topic of supporting (or not)
> a
> > more recent minimum CMake version.
>
> I would love to have everyone use 2.6, but I think 2.4 is more reasonable,
> until Lenny is out :-)
>
> Before you take a close look at the CMake logic, checkout SVN trunk,
> because
> some changes were already done by other people. RTT should today about work
> with non-standard installs. Just set CMAKE_INCLUDE_PATH correctly.
>
> I'm not going to invest time coding this. Any patches for the build system
> will most likely be accepted, but realise that buildsystem changes always
> take
> more time than you estimate, mainly because everything operates in a
> 'global
> space'.
>
> Peter
> --
> Peter Soetens -- FMTC -- <http://www.fmtc.be>
>

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by sspr on Tue, 2009-03-03 10:05.

On Monday 02 March 2009 18:01:16 Adolfo Rodríguez Tsouroukdissian wrote:
> Hi all,
>
> I've been checking out the RTT 1.8 CMakeLists scripts, in particular where
> the external dependencies are found, and I still believe that some
> improvements can be done.

I'm grateful for all you guys taking this thing so seriously. We ported to
cmake in the 2.2 days, and very little information was available back then
(the wiki was in its infancy) and we/I had to figure out a lot by trial and
error. There hasn't been much maintenance in that area, because (until
recently) there haven't been much complaints.

Just to provide my 2 cents in the 'idea' behind the current RTT macros:

* Since .cpp/.hpp files are scattered in 'src' and subdirectories, we needed to
accumulate them in environment variables SRCS and HPPS. In the end, they are
used to build the orocos-rtt-<target> library (so/dll and/or .a/lib)
* RTT only really depends on boost, rtt-corba relies on TAO or OMNIORB.
* Xerces is very optional. It only slightly adds better debugging of broken
XML files in comparison to the built-in tiny-xml library.
* All environment detection is done from the top level CMakeLists.txt file (by
inclusion of macros in config/...). Such that the flags are available to doc,
src and tests.
* We distinguish between the build/include/link flags for building liborocos-
rtt-<target> (used std CMAKE macros) and for the orocos-rtt-<target>.pc file
(used *_FLAGS variables). That's why you see the difference. The .pc file needs
the -I/-L/-l flags. Take a look at src/orocos-rtt.pc.in and src/corba/orocos-
rtt-corba.pc.in. That explains the 'double' use you see. AFAIK, .pc files are
Unix-specific.
* The unit tests also use/need the same flags as the library build.
* All parameter tuning is done in src/CMakeLists.txt, even those that are OS
specific. So given the user options and installed/available services, that
cmake file decides the final build flags for the library. In principle, the
environment detection in the top level cmake file should not set any of these
flags/include directories/etc.

About the same applies to OCL. Environment variables are used to collect flags
from the subdirectories (in order to create the .pc file, see
OROCOS_COMPONENTS_CFLAGS for example). One could argue that you need one .pc
file for each component, and not a global one.

I'm not at all opposing standardising on cmake 2.6, although I'll need a
backport for etch in that case, but that's my problem, not yours :-) I believe
2.6 is a huge improvement over 2.4, so please, make it yourself as easy as
possible.

Peter
--
Peter Soetens -- FMTC -- <http://www.fmtc.be>
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by fosini on Tue, 2009-03-03 10:50.

On Tue, Mar 3, 2009 at 10:59 AM, Peter Soetens <peter [dot] soetens [..] ...>wrote:

> On Monday 02 March 2009 18:01:16 Adolfo Rodríguez Tsouroukdissian wrote:
> > Hi all,
> >
> > I've been checking out the RTT 1.8 CMakeLists scripts, in particular
> where
> > the external dependencies are found, and I still believe that some
> > improvements can be done.
>
> I'm grateful for all you guys taking this thing so seriously. We ported to
> cmake in the 2.2 days, and very little information was available back then
> (the wiki was in its infancy) and we/I had to figure out a lot by trial and
> error. There hasn't been much maintenance in that area, because (until
> recently) there haven't been much complaints.
>
> Just to provide my 2 cents in the 'idea' behind the current RTT macros:
>
> * Since .cpp/.hpp files are scattered in 'src' and subdirectories, we
> needed to
> accumulate them in environment variables SRCS and HPPS. In the end, they
> are
> used to build the orocos-rtt-<target> library (so/dll and/or .a/lib)

I've noticed how environment variables are used to accumulate .cpp/.hpp
files. If this wants/needs to be changed (YAGNI?), CMake 2.6 (but not 2.4)
provides _somewhat_ of a workaround for this. The set command can be invoked
as

set(<variable> <value> PARENT_SCOPE)

Quoting the doc:
"If PARENT_SCOPE is present, the variable will be set in the scope above the
current scope. Each new directory or function creates a new scope. This
command will set the value of a variable into the parent directory or
calling function (whichever is applicable to the case at hand)."
This means that we can propagate values to the scope of the cmake file that
included the current one, but we cannot propagate values to say a
grandparent file, unless we accumulate them through successive set calls
with PARENT_SCOPE (which is what I have done in other projects).

Also, cmake allows to independently set properties (preprocessor
definitions, compiler/linker flags) to groups of source files, targets, and
directories, which I think should be enough to set up quite a complex
project :), which brings me to:

* We distinguish between the build/include/link flags for building
> liborocos-
> rtt-<target> (used std CMAKE macros) and for the orocos-rtt-<target>.pc
> file
> (used *_FLAGS variables). That's why you see the difference. The .pc file
> needs
> the -I/-L/-l flags. Take a look at src/orocos-rtt.pc.in and
> src/corba/orocos-
> rtt-corba.pc.in. That explains the 'double' use you see. AFAIK, .pc files
> are
> Unix-specific.

AFAIK, there is no built-in script for generating .pc files. After a (very)
quick search, I only found this old (2006) post:
//www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html" title="http://www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html">http://www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html
One alternative that could be considered to be used along with, or instead
of pkgconfig, is to use the importing/exporting functionalities of CMake.
I've used it in the 2.4 days and it worked pretty much like pkgconfig, that
is, it configures and installs a text file usually in the lib/<package_name>
folder containing include/lib dirs, dependencies, compiler/linker flags, and
so forth. The nice thing is that cmake takes care of all the hard work of
tracking dependencies, flags, ...., and that it is portable to all the
platforms supported by cmake.
I know that the export/import functionalities have been heavily overhauled
for cmake 2.6, but haven't had the chance to play around with them.
Oh, and another cool thing, if you export your project with cmake, then it
can be automagically found by find_package(Foo), without the need of writing
an extra FindFoo.cmake module. Some notes on the subject can be found here

http://www.vtk.org/Wiki/CMake_2.6_Notes

OK, that's it for now. Hope this proves useful.

Cheers!

>
> * The unit tests also use/need the same flags as the library build.
> * All parameter tuning is done in src/CMakeLists.txt, even those that are
> OS
> specific. So given the user options and installed/available services, that
> cmake file decides the final build flags for the library. In principle, the
> environment detection in the top level cmake file should not set any of
> these
> flags/include directories/etc.
>
> About the same applies to OCL. Environment variables are used to collect
> flags
> from the subdirectories (in order to create the .pc file, see
> OROCOS_COMPONENTS_CFLAGS for example). One could argue that you need one
> .pc
> file for each component, and not a global one.
>
> I'm not at all opposing standardising on cmake 2.6, although I'll need a
> backport for etch in that case, but that's my problem, not yours :-) I
> believe
> 2.6 is a huge improvement over 2.4, so please, make it yourself as easy as
> possible.
>
> Peter
> --
> Peter Soetens -- FMTC -- <http://www.fmtc.be>
>

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by fosini on Wed, 2009-03-25 14:45.

Now that the CMake topic is hot again, I'd like to mention that I've been
working on writing FindOrocosRTT and FindOrocosOCL scripts that do not rely
on pkgconfig. The main motivation for it --apart from not depending on
pkgconfig, which may not always be available-- is that setting up the
pkgconfig files was one of the causes of the "flag accumulation problem".
So, providing a way of finding RTT and OCL without pkgconfig may be a good
starting point for improving the CMake logic.

Before posting the files, I'd like to have some feedback on what the desired
module behavior should be, especially for RTT (this post is long).
Currently, they work like this:

Orocos RTT:

- If RTT is installed in an unusual location, specify it either by means of
the OrocosRTT_ROOT_DIR environment variable, or through a CMake (cache)
variable with the same name.

- Set the desired target: (also works with all caps OROCOS_TARGET variable)

set(Orocos_TARGET xenomai)

Question: If unspecified, should we force gnulinux (or something else) or
issue an error?

- Invoke find_package. Multiple signatures can be used. Examples:

find_package(OrocosRTT)
find_package(OrocosRTT REQUIRED QUIET) # Error if not found, non-verbose
output
find_package(OrocosRTT 1.6 REQUIRED) # Error if not found, or if version is
< 1.6
find_package(OrocosRTT 1.8 EXACT REQUIRED) # Error if not found, or if
version != 1.8 (version pinning)

- The script creates the following variables (equivalents in all caps also
exist for compatibility, e.g., OROCOS_RTT_FOUND):

OrocosRTT_FOUND: Boolean that indicates if the package was found
OrocosRTT_INCLUDE_DIRS: Paths to the necessary header files
OrocosRTT_LIBRARIES: Package libraries
OrocosRTT_DEFINITIONS: Preprocessor definitions required by the package

It is now the user's responsability to call
include_directories(${OrocosRTT_INCLUDE_DIRS}) and
target_link_libraries(${foo OrocosRTT_LIBRARIES}) at the appropriate scope,
so Orocos-related flags are not set when compiling non-Orocos source files.

Question: I'm not sure what the best way of handling corba support should
be. Leaving backwards compatibility aside for one moment, and speaking of
your wishlist, would you rather:
- Use a OrocosRTT_CORBA_LIBS variable (similar to what is currently done)
- Extend the find_package signature so that it can be invoked as
find_package(OrocosRTT COMPONENTS corba) # with corba support
- Something else

Also, I haven't incorporated FindTAO and FindOmniORB scripts into
FindOrocosRTT (TODO) so the corba part is not robust at the moment.

OrocosOCL:

I think FindOrocosOCL is pretty much in shape. You can specify the
OrocosOCL_ROOT_DIR environment of CMake variable for unusual locations, and
the find_package signature is:

find_package(OrocosOCL REQUIRED COMPONENTS deployment deployment-corba
reporting)

where you specify each needed OCL component (nice syntax coincidence!). If
no component is specified, only the ocl-core library is included in
OrocosOCL_LIBRARIES

One thing: I have not added version support for OCL, since I found no header
file to parse with relevant version info (like rtt-config.h for RTT).

Looking forward for some comments, suggestions, and whether you think this
is going to be really useful or not. If there is interest, I could be
posting the modules in the coming weeks.

Cheers,

On Tue, Mar 3, 2009 at 11:49 AM, Adolfo Rodríguez Tsouroukdissian <
adolfo [dot] rodriguez [..] ...> wrote:

>
>
> On Tue, Mar 3, 2009 at 10:59 AM, Peter Soetens <peter [dot] soetens [..] ...>wrote:
>
>> On Monday 02 March 2009 18:01:16 Adolfo Rodríguez Tsouroukdissian wrote:
>> > Hi all,
>> >
>> > I've been checking out the RTT 1.8 CMakeLists scripts, in particular
>> where
>> > the external dependencies are found, and I still believe that some
>> > improvements can be done.
>>
>> I'm grateful for all you guys taking this thing so seriously. We ported to
>> cmake in the 2.2 days, and very little information was available back then
>> (the wiki was in its infancy) and we/I had to figure out a lot by trial
>> and
>> error. There hasn't been much maintenance in that area, because (until
>> recently) there haven't been much complaints.
>>
>> Just to provide my 2 cents in the 'idea' behind the current RTT macros:
>>
>> * Since .cpp/.hpp files are scattered in 'src' and subdirectories, we
>> needed to
>> accumulate them in environment variables SRCS and HPPS. In the end, they
>> are
>> used to build the orocos-rtt-<target> library (so/dll and/or .a/lib)
>
>
> I've noticed how environment variables are used to accumulate .cpp/.hpp
> files. If this wants/needs to be changed (YAGNI?), CMake 2.6 (but not 2.4)
> provides _somewhat_ of a workaround for this. The set command can be invoked
> as
>
> set(<variable> <value> PARENT_SCOPE)
>
> Quoting the doc:
> "If PARENT_SCOPE is present, the variable will be set in the scope above
> the current scope. Each new directory or function creates a new scope. This
> command will set the value of a variable into the parent directory or
> calling function (whichever is applicable to the case at hand)."
> This means that we can propagate values to the scope of the cmake file that
> included the current one, but we cannot propagate values to say a
> grandparent file, unless we accumulate them through successive set calls
> with PARENT_SCOPE (which is what I have done in other projects).
>
> Also, cmake allows to independently set properties (preprocessor
> definitions, compiler/linker flags) to groups of source files, targets, and
> directories, which I think should be enough to set up quite a complex
> project :), which brings me to:
>
> * We distinguish between the build/include/link flags for building
>> liborocos-
>> rtt-<target> (used std CMAKE macros) and for the orocos-rtt-<target>.pc
>> file
>> (used *_FLAGS variables). That's why you see the difference. The .pc file
>> needs
>> the -I/-L/-l flags. Take a look at src/orocos-rtt.pc.in and
>> src/corba/orocos-
>> rtt-corba.pc.in. That explains the 'double' use you see. AFAIK, .pc files
>> are
>> Unix-specific.
>
>
> AFAIK, there is no built-in script for generating .pc files. After a (very)
> quick search, I only found this old (2006) post:
> //www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html" title="http://www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html">http://www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html
> One alternative that could be considered to be used along with, or instead
> of pkgconfig, is to use the importing/exporting functionalities of CMake.
> I've used it in the 2.4 days and it worked pretty much like pkgconfig, that
> is, it configures and installs a text file usually in the lib/<package_name>
> folder containing include/lib dirs, dependencies, compiler/linker flags, and
> so forth. The nice thing is that cmake takes care of all the hard work of
> tracking dependencies, flags, ...., and that it is portable to all the
> platforms supported by cmake.
> I know that the export/import functionalities have been heavily overhauled
> for cmake 2.6, but haven't had the chance to play around with them.
> Oh, and another cool thing, if you export your project with cmake, then it
> can be automagically found by find_package(Foo), without the need of writing
> an extra FindFoo.cmake module. Some notes on the subject can be found here
>
> http://www.vtk.org/Wiki/CMake_2.6_Notes
>
> OK, that's it for now. Hope this proves useful.
>
> Cheers!
>
>
>>
>> * The unit tests also use/need the same flags as the library build.
>> * All parameter tuning is done in src/CMakeLists.txt, even those that are
>> OS
>> specific. So given the user options and installed/available services, that
>> cmake file decides the final build flags for the library. In principle,
>> the
>> environment detection in the top level cmake file should not set any of
>> these
>> flags/include directories/etc.
>>
>> About the same applies to OCL. Environment variables are used to collect
>> flags
>> from the subdirectories (in order to create the .pc file, see
>> OROCOS_COMPONENTS_CFLAGS for example). One could argue that you need one
>> .pc
>> file for each component, and not a global one.
>>
>> I'm not at all opposing standardising on cmake 2.6, although I'll need a
>> backport for etch in that case, but that's my problem, not yours :-) I
>> believe
>> 2.6 is a huge improvement over 2.4, so please, make it yourself as easy as
>> possible.
>>
>> Peter
>> --
>> Peter Soetens -- FMTC -- <http://www.fmtc.be>
>>
>
>
>
> --
> Adolfo Rodríguez Tsouroukdissian
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by sspr on Wed, 2009-03-25 20:15.

Hi Adolfo,

I believe your 'Find..' macros are of good use. These points should be taken
into account:

* The current way of specifying non-standard locations is by using
CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH. You should not use a
OrocosRTT_ROOT_DIR. Same for OCL.
* If no OROCOS_TARGET is set, default to gnulinux on Linux systems, win32 on
Windows systems, macosx on MacOS-X.
* About detecting corba. The current way we do it is by allowing as
OROCOS_TARGET also 'gnulinux-corba' (or macosx-corba,...) instead. But that
clutters up your non-corba flags. That could be solved by specifying a
'storage' variable prefix as last argument like:
SET(OROCOS_TARGET gnulinux-corba)
findPackage(OrocosRTT 1.6 REQUIRED OROCOS_RTT_CORBA)
But I'm not a cmake guru, so that might be a bad idea...

The rest looks ok, although I would prefer to use OROCOCS_RTT_* instead of
OrocosRTT_*... but that might be ou of habit.

You also provided the FindXerces macro earlier. Could you provide that as a
patch in which the current CMake files actually use it ? Then I can merge it
into trunk and others can test it as well.

Peter

On Wednesday 25 March 2009 15:39:54 Adolfo Rodríguez Tsouroukdissian wrote:
> Now that the CMake topic is hot again, I'd like to mention that I've been
> working on writing FindOrocosRTT and FindOrocosOCL scripts that do not rely
> on pkgconfig. The main motivation for it --apart from not depending on
> pkgconfig, which may not always be available-- is that setting up the
> pkgconfig files was one of the causes of the "flag accumulation problem".
> So, providing a way of finding RTT and OCL without pkgconfig may be a good
> starting point for improving the CMake logic.
>
> Before posting the files, I'd like to have some feedback on what the
> desired module behavior should be, especially for RTT (this post is long).
> Currently, they work like this:
>
> Orocos RTT:
>
> - If RTT is installed in an unusual location, specify it either by means of
> the OrocosRTT_ROOT_DIR environment variable, or through a CMake (cache)
> variable with the same name.
>
> - Set the desired target: (also works with all caps OROCOS_TARGET variable)
>
> set(Orocos_TARGET xenomai)
>
> Question: If unspecified, should we force gnulinux (or something else) or
> issue an error?
>
> - Invoke find_package. Multiple signatures can be used. Examples:
>
> find_package(OrocosRTT)
> find_package(OrocosRTT REQUIRED QUIET) # Error if not found, non-verbose
> output
> find_package(OrocosRTT 1.6 REQUIRED) # Error if not found, or if version is
> < 1.6
> find_package(OrocosRTT 1.8 EXACT REQUIRED) # Error if not found, or if
> version != 1.8 (version pinning)
>
> - The script creates the following variables (equivalents in all caps also
> exist for compatibility, e.g., OROCOS_RTT_FOUND):
>
> OrocosRTT_FOUND: Boolean that indicates if the package was found
> OrocosRTT_INCLUDE_DIRS: Paths to the necessary header files
> OrocosRTT_LIBRARIES: Package libraries
> OrocosRTT_DEFINITIONS: Preprocessor definitions required by the package
>
> It is now the user's responsability to call
> include_directories(${OrocosRTT_INCLUDE_DIRS}) and
> target_link_libraries(${foo OrocosRTT_LIBRARIES}) at the appropriate scope,
> so Orocos-related flags are not set when compiling non-Orocos source files.
>
> Question: I'm not sure what the best way of handling corba support should
> be. Leaving backwards compatibility aside for one moment, and speaking of
> your wishlist, would you rather:
> - Use a OrocosRTT_CORBA_LIBS variable (similar to what is currently done)
> - Extend the find_package signature so that it can be invoked as
> find_package(OrocosRTT COMPONENTS corba) # with corba support
> - Something else
>
> Also, I haven't incorporated FindTAO and FindOmniORB scripts into
> FindOrocosRTT (TODO) so the corba part is not robust at the moment.
>
>
> OrocosOCL:
>
> I think FindOrocosOCL is pretty much in shape. You can specify the
> OrocosOCL_ROOT_DIR environment of CMake variable for unusual locations, and
> the find_package signature is:
>
> find_package(OrocosOCL REQUIRED COMPONENTS deployment deployment-corba
> reporting)
>
> where you specify each needed OCL component (nice syntax coincidence!). If
> no component is specified, only the ocl-core library is included in
> OrocosOCL_LIBRARIES
>
> One thing: I have not added version support for OCL, since I found no
> header file to parse with relevant version info (like rtt-config.h for
> RTT).
>
> Looking forward for some comments, suggestions, and whether you think this
> is going to be really useful or not. If there is interest, I could be
> posting the modules in the coming weeks.
>
> Cheers,
>
> On Tue, Mar 3, 2009 at 11:49 AM, Adolfo Rodríguez Tsouroukdissian <
>
> adolfo [dot] rodriguez [..] ...> wrote:
> > On Tue, Mar 3, 2009 at 10:59 AM, Peter Soetens
<peter [dot] soetens [..] ...>wrote:
> >> On Monday 02 March 2009 18:01:16 Adolfo Rodríguez Tsouroukdissian wrote:
> >> > Hi all,
> >> >
> >> > I've been checking out the RTT 1.8 CMakeLists scripts, in particular
> >>
> >> where
> >>
> >> > the external dependencies are found, and I still believe that some
> >> > improvements can be done.
> >>
> >> I'm grateful for all you guys taking this thing so seriously. We ported
> >> to cmake in the 2.2 days, and very little information was available back
> >> then (the wiki was in its infancy) and we/I had to figure out a lot by
> >> trial and
> >> error. There hasn't been much maintenance in that area, because (until
> >> recently) there haven't been much complaints.
> >>
> >> Just to provide my 2 cents in the 'idea' behind the current RTT macros:
> >>
> >> * Since .cpp/.hpp files are scattered in 'src' and subdirectories, we
> >> needed to
> >> accumulate them in environment variables SRCS and HPPS. In the end, they
> >> are
> >> used to build the orocos-rtt-<target> library (so/dll and/or .a/lib)
> >
> > I've noticed how environment variables are used to accumulate .cpp/.hpp
> > files. If this wants/needs to be changed (YAGNI?), CMake 2.6 (but not
> > 2.4) provides _somewhat_ of a workaround for this. The set command can be
> > invoked as
> >
> > set(<variable> <value> PARENT_SCOPE)
> >
> > Quoting the doc:
> > "If PARENT_SCOPE is present, the variable will be set in the scope above
> > the current scope. Each new directory or function creates a new scope.
> > This command will set the value of a variable into the parent directory
> > or calling function (whichever is applicable to the case at hand)." This
> > means that we can propagate values to the scope of the cmake file that
> > included the current one, but we cannot propagate values to say a
> > grandparent file, unless we accumulate them through successive set calls
> > with PARENT_SCOPE (which is what I have done in other projects).
> >
> > Also, cmake allows to independently set properties (preprocessor
> > definitions, compiler/linker flags) to groups of source files, targets,
> > and directories, which I think should be enough to set up quite a complex
> > project :), which brings me to:
> >
> > * We distinguish between the build/include/link flags for building
> >
> >> liborocos-
> >> rtt-<target> (used std CMAKE macros) and for the orocos-rtt-<target>.pc
> >> file
> >> (used *_FLAGS variables). That's why you see the difference. The .pc
> >> file needs
> >> the -I/-L/-l flags. Take a look at src/orocos-rtt.pc.in and
> >> src/corba/orocos-
> >> rtt-corba.pc.in. That explains the 'double' use you see. AFAIK, .pc
> >> files are
> >> Unix-specific.
> >
> > AFAIK, there is no built-in script for generating .pc files. After a
> > (very) quick search, I only found this old (2006) post:
> > //www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html" title="http://www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html">http://www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html
> > One alternative that could be considered to be used along with, or
> > instead of pkgconfig, is to use the importing/exporting functionalities
> > of CMake. I've used it in the 2.4 days and it worked pretty much like
> > pkgconfig, that is, it configures and installs a text file usually in the
> > lib/<package_name> folder containing include/lib dirs, dependencies,
> > compiler/linker flags, and so forth. The nice thing is that cmake takes
> > care of all the hard work of tracking dependencies, flags, ...., and that
> > it is portable to all the platforms supported by cmake.
> > I know that the export/import functionalities have been heavily
> > overhauled for cmake 2.6, but haven't had the chance to play around with
> > them. Oh, and another cool thing, if you export your project with cmake,
> > then it can be automagically found by find_package(Foo), without the need
> > of writing an extra FindFoo.cmake module. Some notes on the subject can
> > be found here
> >
> > http://www.vtk.org/Wiki/CMake_2.6_Notes
> >
> > OK, that's it for now. Hope this proves useful.
> >
> > Cheers!
> >
> >> * The unit tests also use/need the same flags as the library build.
> >> * All parameter tuning is done in src/CMakeLists.txt, even those that
> >> are OS
> >> specific. So given the user options and installed/available services,
> >> that cmake file decides the final build flags for the library. In
> >> principle, the
> >> environment detection in the top level cmake file should not set any of
> >> these
> >> flags/include directories/etc.
> >>
> >> About the same applies to OCL. Environment variables are used to collect
> >> flags
> >> from the subdirectories (in order to create the .pc file, see
> >> OROCOS_COMPONENTS_CFLAGS for example). One could argue that you need one
> >> .pc
> >> file for each component, and not a global one.
> >>
> >> I'm not at all opposing standardising on cmake 2.6, although I'll need a
> >> backport for etch in that case, but that's my problem, not yours :-) I
> >> believe
> >> 2.6 is a huge improvement over 2.4, so please, make it yourself as easy
> >> as possible.
> >>
> >> Peter
> >> --
> >> Peter Soetens -- FMTC -- <http://www.fmtc.be>
> >
> > --
> > Adolfo Rodríguez Tsouroukdissian
> >
> > Robotics engineer
> > PAL ROBOTICS S.L
> > http://www.pal-robotics.com
> > Tel. +34.93.414.53.47
> > Fax.+34.93.209.11.09

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by fosini on Fri, 2009-03-27 13:00.

On Wed, Mar 25, 2009 at 9:11 PM, Peter Soetens <peter [dot] soetens [..] ...>wrote:

> Hi Adolfo,
>
> I believe your 'Find..' macros are of good use. These points should be
> taken
> into account:
>
> * The current way of specifying non-standard locations is by using
> CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH. You should not use a
> OrocosRTT_ROOT_DIR. Same for OCL.
> * If no OROCOS_TARGET is set, default to gnulinux on Linux systems, win32
> on
> Windows systems, macosx on MacOS-X.
> * About detecting corba. The current way we do it is by allowing as
> OROCOS_TARGET also 'gnulinux-corba' (or macosx-corba,...) instead. But that
> clutters up your non-corba flags. That could be solved by specifying a
> 'storage' variable prefix as last argument like:
> SET(OROCOS_TARGET gnulinux-corba)
> findPackage(OrocosRTT 1.6 REQUIRED OROCOS_RTT_CORBA)
> But I'm not a cmake guru, so that might be a bad idea...
>
> The rest looks ok, although I would prefer to use OROCOCS_RTT_* instead of
> OrocosRTT_*... but that might be ou of habit.
>
> You also provided the FindXerces macro earlier. Could you provide that as a
> patch in which the current CMake files actually use it ? Then I can merge
> it
> into trunk and others can test it as well.

I'm attaching to this message a patch that does the following:
- Provides the FindXerces LibFindMacros scripts. The latter has not been
written by me (only minor changes in output messages)
- Modifies necessary cmake files to use FindXerces
- Changed the boost finding logic so that it uses FindBoost (provided by
CMake)

Tested it with gnulinux target, boost versions 1.34 and 1.35, and two
installations of xerces (standard location and nonstandard location).

Cheers,

Adolfo

> Peter
>
> On Wednesday 25 March 2009 15:39:54 Adolfo Rodríguez Tsouroukdissian wrote:
> > Now that the CMake topic is hot again, I'd like to mention that I've been
> > working on writing FindOrocosRTT and FindOrocosOCL scripts that do not
> rely
> > on pkgconfig. The main motivation for it --apart from not depending on
> > pkgconfig, which may not always be available-- is that setting up the
> > pkgconfig files was one of the causes of the "flag accumulation problem".
> > So, providing a way of finding RTT and OCL without pkgconfig may be a
> good
> > starting point for improving the CMake logic.
> >
> > Before posting the files, I'd like to have some feedback on what the
> > desired module behavior should be, especially for RTT (this post is
> long).
> > Currently, they work like this:
> >
> > Orocos RTT:
> >
> > - If RTT is installed in an unusual location, specify it either by means
> of
> > the OrocosRTT_ROOT_DIR environment variable, or through a CMake (cache)
> > variable with the same name.
> >
> > - Set the desired target: (also works with all caps OROCOS_TARGET
> variable)
> >
> > set(Orocos_TARGET xenomai)
> >
> > Question: If unspecified, should we force gnulinux (or something else) or
> > issue an error?
> >
> > - Invoke find_package. Multiple signatures can be used. Examples:
> >
> > find_package(OrocosRTT)
> > find_package(OrocosRTT REQUIRED QUIET) # Error if not found, non-verbose
> > output
> > find_package(OrocosRTT 1.6 REQUIRED) # Error if not found, or if version
> is
> > < 1.6
> > find_package(OrocosRTT 1.8 EXACT REQUIRED) # Error if not found, or if
> > version != 1.8 (version pinning)
> >
> > - The script creates the following variables (equivalents in all caps
> also
> > exist for compatibility, e.g., OROCOS_RTT_FOUND):
> >
> > OrocosRTT_FOUND: Boolean that indicates if the package was found
> > OrocosRTT_INCLUDE_DIRS: Paths to the necessary header files
> > OrocosRTT_LIBRARIES: Package libraries
> > OrocosRTT_DEFINITIONS: Preprocessor definitions required by the package
> >
> > It is now the user's responsability to call
> > include_directories(${OrocosRTT_INCLUDE_DIRS}) and
> > target_link_libraries(${foo OrocosRTT_LIBRARIES}) at the appropriate
> scope,
> > so Orocos-related flags are not set when compiling non-Orocos source
> files.
> >
> > Question: I'm not sure what the best way of handling corba support should
> > be. Leaving backwards compatibility aside for one moment, and speaking of
> > your wishlist, would you rather:
> > - Use a OrocosRTT_CORBA_LIBS variable (similar to what is currently done)
> > - Extend the find_package signature so that it can be invoked as
> > find_package(OrocosRTT COMPONENTS corba) # with corba support
> > - Something else
> >
> > Also, I haven't incorporated FindTAO and FindOmniORB scripts into
> > FindOrocosRTT (TODO) so the corba part is not robust at the moment.
> >
> >
> > OrocosOCL:
> >
> > I think FindOrocosOCL is pretty much in shape. You can specify the
> > OrocosOCL_ROOT_DIR environment of CMake variable for unusual locations,
> and
> > the find_package signature is:
> >
> > find_package(OrocosOCL REQUIRED COMPONENTS deployment deployment-corba
> > reporting)
> >
> > where you specify each needed OCL component (nice syntax coincidence!).
> If
> > no component is specified, only the ocl-core library is included in
> > OrocosOCL_LIBRARIES
> >
> > One thing: I have not added version support for OCL, since I found no
> > header file to parse with relevant version info (like rtt-config.h for
> > RTT).
> >
> > Looking forward for some comments, suggestions, and whether you think
> this
> > is going to be really useful or not. If there is interest, I could be
> > posting the modules in the coming weeks.
> >
> > Cheers,
> >
> > On Tue, Mar 3, 2009 at 11:49 AM, Adolfo Rodríguez Tsouroukdissian <
> >
> > adolfo [dot] rodriguez [..] ...> wrote:
> > > On Tue, Mar 3, 2009 at 10:59 AM, Peter Soetens
> <peter [dot] soetens [..] ...>wrote:
> > >> On Monday 02 March 2009 18:01:16 Adolfo Rodríguez Tsouroukdissian
> wrote:
> > >> > Hi all,
> > >> >
> > >> > I've been checking out the RTT 1.8 CMakeLists scripts, in particular
> > >>
> > >> where
> > >>
> > >> > the external dependencies are found, and I still believe that some
> > >> > improvements can be done.
> > >>
> > >> I'm grateful for all you guys taking this thing so seriously. We
> ported
> > >> to cmake in the 2.2 days, and very little information was available
> back
> > >> then (the wiki was in its infancy) and we/I had to figure out a lot by
> > >> trial and
> > >> error. There hasn't been much maintenance in that area, because (until
> > >> recently) there haven't been much complaints.
> > >>
> > >> Just to provide my 2 cents in the 'idea' behind the current RTT
> macros:
> > >>
> > >> * Since .cpp/.hpp files are scattered in 'src' and subdirectories, we
> > >> needed to
> > >> accumulate them in environment variables SRCS and HPPS. In the end,
> they
> > >> are
> > >> used to build the orocos-rtt-<target> library (so/dll and/or .a/lib)
> > >
> > > I've noticed how environment variables are used to accumulate .cpp/.hpp
> > > files. If this wants/needs to be changed (YAGNI?), CMake 2.6 (but not
> > > 2.4) provides _somewhat_ of a workaround for this. The set command can
> be
> > > invoked as
> > >
> > > set(<variable> <value> PARENT_SCOPE)
> > >
> > > Quoting the doc:
> > > "If PARENT_SCOPE is present, the variable will be set in the scope
> above
> > > the current scope. Each new directory or function creates a new scope.
> > > This command will set the value of a variable into the parent directory
> > > or calling function (whichever is applicable to the case at hand)."
> This
> > > means that we can propagate values to the scope of the cmake file that
> > > included the current one, but we cannot propagate values to say a
> > > grandparent file, unless we accumulate them through successive set
> calls
> > > with PARENT_SCOPE (which is what I have done in other projects).
> > >
> > > Also, cmake allows to independently set properties (preprocessor
> > > definitions, compiler/linker flags) to groups of source files, targets,
> > > and directories, which I think should be enough to set up quite a
> complex
> > > project :), which brings me to:
> > >
> > > * We distinguish between the build/include/link flags for building
> > >
> > >> liborocos-
> > >> rtt-<target> (used std CMAKE macros) and for the
> orocos-rtt-<target>.pc
> > >> file
> > >> (used *_FLAGS variables). That's why you see the difference. The .pc
> > >> file needs
> > >> the -I/-L/-l flags. Take a look at src/orocos-rtt.pc.in and
> > >> src/corba/orocos-
> > >> rtt-corba.pc.in. That explains the 'double' use you see. AFAIK, .pc
> > >> files are
> > >> Unix-specific.
> > >
> > > AFAIK, there is no built-in script for generating .pc files. After a
> > > (very) quick search, I only found this old (2006) post:
> > > //www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html" title="http://www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html">http://www [dot] mail-archive [dot] com/cmake [..] .../msg02856.html
> > > One alternative that could be considered to be used along with, or
> > > instead of pkgconfig, is to use the importing/exporting functionalities
> > > of CMake. I've used it in the 2.4 days and it worked pretty much like
> > > pkgconfig, that is, it configures and installs a text file usually in
> the
> > > lib/<package_name> folder containing include/lib dirs, dependencies,
> > > compiler/linker flags, and so forth. The nice thing is that cmake takes
> > > care of all the hard work of tracking dependencies, flags, ...., and
> that
> > > it is portable to all the platforms supported by cmake.
> > > I know that the export/import functionalities have been heavily
> > > overhauled for cmake 2.6, but haven't had the chance to play around
> with
> > > them. Oh, and another cool thing, if you export your project with
> cmake,
> > > then it can be automagically found by find_package(Foo), without the
> need
> > > of writing an extra FindFoo.cmake module. Some notes on the subject can
> > > be found here
> > >
> > > http://www.vtk.org/Wiki/CMake_2.6_Notes
> > >
> > > OK, that's it for now. Hope this proves useful.
> > >
> > > Cheers!
> > >
> > >> * The unit tests also use/need the same flags as the library build.
> > >> * All parameter tuning is done in src/CMakeLists.txt, even those that
> > >> are OS
> > >> specific. So given the user options and installed/available services,
> > >> that cmake file decides the final build flags for the library. In
> > >> principle, the
> > >> environment detection in the top level cmake file should not set any
> of
> > >> these
> > >> flags/include directories/etc.
> > >>
> > >> About the same applies to OCL. Environment variables are used to
> collect
> > >> flags
> > >> from the subdirectories (in order to create the .pc file, see
> > >> OROCOS_COMPONENTS_CFLAGS for example). One could argue that you need
> one
> > >> .pc
> > >> file for each component, and not a global one.
> > >>
> > >> I'm not at all opposing standardising on cmake 2.6, although I'll need
> a
> > >> backport for etch in that case, but that's my problem, not yours :-) I
> > >> believe
> > >> 2.6 is a huge improvement over 2.4, so please, make it yourself as
> easy
> > >> as possible.
> > >>
> > >> Peter
> > >> --
> > >> Peter Soetens -- FMTC -- <http://www.fmtc.be>
> > >
> > > --
> > > Adolfo Rodríguez Tsouroukdissian
> > >
> > > Robotics engineer
> > > PAL ROBOTICS S.L
> > > http://www.pal-robotics.com
> > > Tel. +34.93.414.53.47
> > > Fax.+34.93.209.11.09
>
> --
> Peter Soetens -- FMTC -- <http://www.fmtc.be>
>
>

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by Sylvain Joyeux on Thu, 2009-03-26 10:45.

I personally think that using pkg-config should be the way to go.

First, do you really have an example for a context with no pkg-config where the
RTT (and CMake for that matter) run ?

Second, all the logic you are putting in there is actually the one that should
be used to set up the pkg-config file. Except that, if no valid pkg-config file is
generated, then *all* packages that use the RTT have to use the FindOrocosRTT
cmake file. And update it whenever the dependency logic have changed.

That's the point of pkg-config files: the burden of dependency logic is on the
.pc file provider (here, the RTT) instead of on *all* the packages that are
using RTT.

Sylvain

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by fosini on Thu, 2009-03-26 14:25.

On Thu, Mar 26, 2009 at 10:53 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:

> I personally think that using pkg-config should be the way to go.
>
> First, do you really have an example for a context with no pkg-config where
> the
> RTT (and CMake for that matter) run ?
>
> Second, all the logic you are putting in there is actually the one that
> should
> be used to set up the pkg-config file. Except that, if no valid pkg-config
> file is
> generated, then *all* packages that use the RTT have to use the
> FindOrocosRTT
> cmake file. And update it whenever the dependency logic have changed.
>

In case pkgconfig is still the way to go, then we should investigate if the
generation of .pc files can be done in a way that minimizes or eliminated
the flag accumulation problem. The main motivation for the post is not to do
away with pkgconfig, but to propose an incremental way to --little by
little-- improve the Orocos CMake scripts. Finding external dependencies and
making Orocos easy to find by cmake are the key issues to me.
So, is there a better alternative for populating the fields needed by a
pkgconfig file? if so, how could it be implemented? I currently don't have a
clear answer for this.

> That's the point of pkg-config files: the burden of dependency logic is on
> the
> .pc file provider (here, the RTT) instead of on *all* the packages that are
> using RTT.

I don't fully agree. It is true that with pkgconfig, populating the list of
dependencies, include folders, flags, etc. is deferred to the OrocosRTT
build. However, you still need a FindOrocosRTT script, and the one currently
packaged with OCL is not just a "dumb" script that translates a .pc file to
CMake variables, it actually has a quite complicated logic: It makes
decisions based on the RTT version and searches for headers
(target-specific, corba related). My guess is that future versions of RTT
_will_ require an update of the FindOrocosRTT script, either because a new
target or transport layer was added, or because a newer version exposes
additional CMake variables, or because (you name it...)

One alternative, of course, would be to see if it is possible to strip down
a pkgconfig-based FindOrocosRTT to be really simple and dumb, yet remain
flexible over time (possible?). Otherwise, we will still have to maintain
FindOrocosRTT scripts, or even worse, leave this task to the end-user and
only provide the .pc files.

I'm open to hearing your suggestions. In the mean time, I think I'll try to
polish a little more my proposal and post it, so you can try it out and
decide if it really adds something to the project.

Cheers!

>
> Sylvain
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by sspr on Thu, 2009-03-26 15:10.

On Thursday 26 March 2009 15:21:29 Adolfo Rodríguez Tsouroukdissian wrote:
> On Thu, Mar 26, 2009 at 10:53 AM, Sylvain Joyeux
<sylvain [dot] joyeux [..] ...>wrote:
> > I personally think that using pkg-config should be the way to go.
> >
> > First, do you really have an example for a context with no pkg-config
> > where the
> > RTT (and CMake for that matter) run ?
> >
> > Second, all the logic you are putting in there is actually the one that
> > should
> > be used to set up the pkg-config file. Except that, if no valid
> > pkg-config file is
> > generated, then *all* packages that use the RTT have to use the
> > FindOrocosRTT
> > cmake file. And update it whenever the dependency logic have changed.
>
> In case pkgconfig is still the way to go, then we should investigate if the
> generation of .pc files can be done in a way that minimizes or eliminated
> the flag accumulation problem. The main motivation for the post is not to
> do away with pkgconfig, but to propose an incremental way to --little by
> little-- improve the Orocos CMake scripts. Finding external dependencies
> and making Orocos easy to find by cmake are the key issues to me.
> So, is there a better alternative for populating the fields needed by a
> pkgconfig file? if so, how could it be implemented? I currently don't have
> a clear answer for this.

The flag accumulation problem is a CMake bug and not so much a pkgconfig bug.
pkgconfig solves flag handling very nicely (it removes duplicates etc).

I thought that pkgconfig was quite Linux specific and that for that reason, a
more 'cmake-like' approach was welcome. How easily do Mac OS-X and Win32
platforms handle .pc files ?

Also note that the .pc file for OCL is mediocre. It groups all libraries
(forcing users of the .pc file to link to all components !) instead of creating
one .pc file for each library. I hoped that Adolfo's patch would solve that as
well.

Peter

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by snrkiwi on Thu, 2009-03-26 15:30.

On Thursday, March 26, 2009, at 11:08AM, "Peter Soetens" <peter [dot] soetens [..] ...> wrote:
>On Thursday 26 March 2009 15:21:29 Adolfo Rodríguez Tsouroukdissian wrote:
>> On Thu, Mar 26, 2009 at 10:53 AM, Sylvain Joyeux
><sylvain [dot] joyeux [..] ...>wrote:
>> > I personally think that using pkg-config should be the way to go.
>> >
>> > First, do you really have an example for a context with no pkg-config
>> > where the
>> > RTT (and CMake for that matter) run ?
>> >
>> > Second, all the logic you are putting in there is actually the one that
>> > should
>> > be used to set up the pkg-config file. Except that, if no valid
>> > pkg-config file is
>> > generated, then *all* packages that use the RTT have to use the
>> > FindOrocosRTT
>> > cmake file. And update it whenever the dependency logic have changed.
>>
>> In case pkgconfig is still the way to go, then we should investigate if the
>> generation of .pc files can be done in a way that minimizes or eliminated
>> the flag accumulation problem. The main motivation for the post is not to
>> do away with pkgconfig, but to propose an incremental way to --little by
>> little-- improve the Orocos CMake scripts. Finding external dependencies
>> and making Orocos easy to find by cmake are the key issues to me.
>> So, is there a better alternative for populating the fields needed by a
>> pkgconfig file? if so, how could it be implemented? I currently don't have
>> a clear answer for this.
>
>The flag accumulation problem is a CMake bug and not so much a pkgconfig bug.
>pkgconfig solves flag handling very nicely (it removes duplicates etc).

Agreed, pkgconfig is very nice for this.

>I thought that pkgconfig was quite Linux specific and that for that reason, a
>more 'cmake-like' approach was welcome. How easily do Mac OS-X and Win32
>platforms handle .pc files ?

Mac OS X = Linux behaviour.

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by Klaas Gadeyne on Tue, 2009-03-03 10:40.

[...]
> I'm not at all opposing standardising on cmake 2.6, although I'll need a
> backport for etch in that case, but that's my problem, not yours :-) I believe
> 2.6 is a huge improvement over 2.4, so please, make it yourself as easy as
> possible.

<http://packages.debian.org/etch-backports/cmake>

btw. An ubuntu user that is using debian oldstable? Where is this
world going... ;-P

CMake and finding external dependencies (from Omniorb merge vs O

Submitted by snrkiwi on Mon, 2009-02-09 15:30.

On Feb 9, 2009, at 09:53 , Adolfo Rodríguez wrote:

On Feb 9, 2009, at 05:19 , Adolfo Rodríguez wrote:

<blockquote type="cite">Hi all,

Inspired by the recent posts made by Sylvain and Stephen,

Quote:

I'd feel much better if each external dependency would have its own Find*.cmake script instead of the generic overly complex check_* script.
Finally, there is more complete (and tested) scripts for dependencies like boost, maybe we should use it.

The corba bit you mentioned, yes. Also, the way we accumulate flags, which I know has been causing Peter problems recently.

Possibly I would argue for this, in the CMake recommended fashion

FIND_FILE(... NO_DEFAULT_PATH)

FIND_FILE(...) ** not done if the above finds it

I currently do this with one single command, using the HINTS keyword I mention above, but is only supported in CMake 2.6.1 and later:
FIND_FILE(... HINTS /path/to/hints PATH /other/paths)
What CMake does is to search in HINTS before PATH and the system directories. The complete search process is detailed here. This of course brings in the discussion the topic of supporting (or not) a more recent minimum CMake version.

Look at the very last paragraph of FIND_FILE, at the link you sent above. That way we don't have to mention any specific path, and just add additional paths (that are searched first in the above double FIND_XXX() scheme) to environment or CMake variables. I am *not* sure how you work this with IDE development. Would like to hear from Eclipse users here ...

I would advocate a long-term goal of no hard-coded paths anywhere in our CMake files. They should all come from external user customization of the build, either via environment variables or from optional user-specific CMake configuration files that add to CMake versions of said environtment variables (recently mentioned by a couple of people on the ML w.r.t. Windoze porting effort). There is a *lot* of CMake code in Orocos that uses hard-code paths ...