New find macros for Orocos RTT/OCL and user components
| Submitted by sspr on Tue, 2009-06-23 08:55 |
I have created an example Orocos component application that uses newly
written find macros for cmake.
This requires cmake 2.6.0 or later.
The user only needs to write this CMakeLists.txt file in a directory:
cmake_minimum_required(VERSION 2.6) include(CreateComponent.cmake) create_component(quicky VERSION 1.0.0 Quicky.cpp )
Where VERSION is the version of the component. I defaulted to RTT/OCL 1.6.0.
Say that your component requires RTT 1.8.2 or later *and* requires the
corba library,
then change the above to:
cmake_minimum_required(VERSION 2.6) include(CreateComponent.cmake) find_package(Orocos-RTT 1.8.2 REQUIRED corba) create_component(quicky VERSION 1.0.0 Quicky.cpp )
You are allowed to specify package components during find_package,
although we only have one currently: corba
A similar thing can be done for OCL:
cmake_minimum_required(VERSION 2.6) include(CreateComponent.cmake) find_package(Orocos-OCL 1.8.1 REQUIRED reporting) #require reporting component create_component(quicky VERSION 1.0.0 Quicky.cpp )
An OCL component is always looked for in this way: orocos-ocl-<componentname>
Proper diagnostics are emitted in case something wasn't found.
The tar ball in attachment should compile on any Orocos platform,
given that CMAKE_INCLUDE_PATH/CMAKE_LIBARARY_PATH
are set if necessary.
tar -xzf quick-1.0.tar.gz cd quicky-1.0 cmake . make
Feedback/patches warmly welcome. I've put it in svn under
https://svn.mech.kuleuven.be/repos/orocos/orocos-apps/quicky
Peter
PS: I used the FindPackageHandleStandardArgs macro instead of the
LibFindMacros, in order to have no dependencies in FindOrocos-RTT and
FindOrocos-OCL.
| Attachment | Size |
|---|---|
| quicky-1.0.tar.gz | 4.02 KB |
New find macros for Orocos RTT/OCL and user components
On Tue, Jun 23, 2009 at 10:47 AM, Peter Soetens <peter [dot] soetens [..] ...>wrote:
> I have created an example Orocos component application that uses newly
> written find macros for cmake.
> This requires cmake 2.6.0 or later.
>
> The user only needs to write this CMakeLists.txt file in a directory:
>
>
> Where VERSION is the version of the component. I defaulted to RTT/OCL
> 1.6.0.
> Say that your component requires RTT 1.8.2 or later *and* requires the
> corba library,
> then change the above to:
>
>
> You are allowed to specify package components during find_package,
> although we only have one currently: corba
>
> A similar thing can be done for OCL:
>
>
> An OCL component is always looked for in this way:
> orocos-ocl-<componentname>
>
> Proper diagnostics are emitted in case something wasn't found.
>
> The tar ball in attachment should compile on any Orocos platform,
> given that CMAKE_INCLUDE_PATH/CMAKE_LIBARARY_PATH
> are set if necessary.
>
>
>
> Feedback/patches warmly welcome. I've put it in svn under
> https://svn.mech.kuleuven.be/repos/orocos/orocos-apps/quicky
>
Looks very good!
A couple of comments:
- What happended to pkgconfig? If you still plan on using it there's the
FindPkgConfig.cmake standard module that provides functionality for parsing
pkgconfig files. Never used it, though.
http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPkgConfig
- I didn't see any checks for external dependencies (Boost, curses, ...)
- There is a specific cmake operator for comparing version numbers:
if(version1 VERSION_LESS version2). It's documented at the end of the if
command http://www.cmake.org/cmake/help/cmake2.6docs.html#command:if
Also, you might be interested in using the VERSION EXACT invocation of
find_package. Check out the attached EnforceVersion.cmake script. It does
just that :)
- I'd define the cmake variables containing the libs, headers, etc. (e.g.,
OROCOS-RTT_INCLUDES, OROCOS-RTT_LIBS,... ) _after_
FindPackageHandleStandardArgs has returned, and _only_ if it succeeded, so
that they are empty if the find process failed. This way we won't end up
with half-baked variables. You can check out an unfinished and untested
prototype FindOrocosOCL.cmake I was working on to see what I mean
(attached). Anyway. Your implementation is a lot more complete.
- Could we rename OROCOS-RTT_INCLUDES to OROCOS-RTT_INCLUDE_DIRS, and
OROCOS-RTT_LIBS to OROCOS-RTT_LIBRARIES, ... so that the names are more
standard? or do we want to maintain backwards-compatibility with the current
naming?
>
> Peter
>
> PS: I used the FindPackageHandleStandardArgs macro instead of the
> LibFindMacros, in order to have no dependencies in FindOrocos-RTT and
> FindOrocos-OCL.
Great! I think that since variable names are in uppercase we should abolish
the nonstandard LibFindMacros. To this end, I'm attaching a slightly
modified FindXerces.cmake that now uses FindPackageHandleStandardArgs. If
you like it, we can work on bringing up to speed the other scripts.
That's it. Too long a message!
Over & out .-
Adolfo
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
New find macros for Orocos RTT/OCL and user components
On Tue, Jun 23, 2009 at 10:47 AM, Peter Soetens <peter [dot] soetens [..] ...>wrote:
> I have created an example Orocos component application that uses newly
> written find macros for cmake.
> This requires cmake 2.6.0 or later.
>
> The user only needs to write this CMakeLists.txt file in a directory:
>
>
> Where VERSION is the version of the component. I defaulted to RTT/OCL
> 1.6.0.
> Say that your component requires RTT 1.8.2 or later *and* requires the
> corba library,
> then change the above to:
>
>
> You are allowed to specify package components during find_package,
> although we only have one currently: corba
>
> A similar thing can be done for OCL:
>
>
> An OCL component is always looked for in this way:
> orocos-ocl-<componentname>
>
> Proper diagnostics are emitted in case something wasn't found.
>
> The tar ball in attachment should compile on any Orocos platform,
> given that CMAKE_INCLUDE_PATH/CMAKE_LIBARARY_PATH
> are set if necessary.
>
>
>
> Feedback/patches warmly welcome. I've put it in svn under
> https://svn.mech.kuleuven.be/repos/orocos/orocos-apps/quicky
>
Looks very good!
A couple of comments:
- What happended to pkgconfig? If you still plan on using it there's the
FindPkgConfig.cmake standard module that provides functionality for parsing
pkgconfig files. Never used it, though.
http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPkgConfig
- I didn't see any checks for external dependencies (Boost, curses, ...)
- There is a specific cmake operator for comparing version numbers:
if(version1 VERSION_LESS version2). It's documented at the end of the if
command http://www.cmake.org/cmake/help/cmake2.6docs.html#command:if
Also, you might be interested in using the VERSION EXACT invocation of
find_package. Check out the attached EnforceVersion.cmake script. It does
just that :)
- I'd define the cmake variables containing the libs, headers, etc. (e.g.,
OROCOS-RTT_INCLUDES, OROCOS-RTT_LIBS,... ) _after_
FindPackageHandleStandardArgs has returned, and _only_ if it succeeded, so
that they are empty if the find process failed. This way we won't end up
with half-baked variables. You can check out an unfinished and untested
prototype FindOrocosOCL.cmake I was working on to see what I mean
(attached). Anyway. Your implementation is a lot more complete.
- Could we rename OROCOS-RTT_INCLUDES to OROCOS-RTT_INCLUDE_DIRS, and
OROCOS-RTT_LIBS to OROCOS-RTT_LIBRARIES, ... so that the names are more
standard? or do we want to maintain backwards-compatibility with the current
naming?
>
> Peter
>
> PS: I used the FindPackageHandleStandardArgs macro instead of the
> LibFindMacros, in order to have no dependencies in FindOrocos-RTT and
> FindOrocos-OCL.
Great! I think that since variable names are in uppercase we should abolish
the nonstandard LibFindMacros. To this end, I'm attaching a slightly
modified FindXerces.cmake that now uses FindPackageHandleStandardArgs. If
you like it, we can work on bringing up to speed the other scripts.
That's it. Too long a message!
Over & out .-
Adolfo
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
New find macros for Orocos RTT/OCL and user components
2009/6/23 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
> On Tue, Jun 23, 2009 at 10:47 AM, Peter Soetens <peter [dot] soetens [..] ...>
>> Feedback/patches warmly welcome. I've put it in svn under
>> https://svn.mech.kuleuven.be/repos/orocos/orocos-apps/quicky
>
> Looks very good!
>
> A couple of comments:
>
> - What happended to pkgconfig? If you still plan on using it there's the
> FindPkgConfig.cmake standard module that provides functionality for parsing
> pkgconfig files. Never used it, though.
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPkgConfig
I don't need it. We only emit the .pc files during installation (for
other build systems to use), but we don't use them ourselves.
>
> - I didn't see any checks for external dependencies (Boost, curses, ...)
These finds are for user code. If the user requires specific boost
stuff, he needs to use FindBoost himself. We assume that once
Orocos-RTT/Orocos-OCL got installed, all its dependencies are fine
too. I'm not checking for libc either :-)
>
> - There is a specific cmake operator for comparing version numbers:
> if(version1 VERSION_LESS version2). It's documented at the end of the if
> command http://www.cmake.org/cmake/help/cmake2.6docs.html#command:if
Oops I intended to use that but got sloppy.
>
> Also, you might be interested in using the VERSION EXACT invocation of
> find_package. Check out the attached EnforceVersion.cmake script. It does
> just that :)
Nice ! will use.
>
> - I'd define the cmake variables containing the libs, headers, etc. (e.g.,
> OROCOS-RTT_INCLUDES, OROCOS-RTT_LIBS,... ) _after_
> FindPackageHandleStandardArgs has returned, and _only_ if it succeeded, so
> that they are empty if the find process failed. This way we won't end up
> with half-baked variables.
OK. I didn't intend to emit OROCOS-RTT_LIBRARY_DIRS but only
OROCOS-RTT_LIBRARIES.
> You can check out an unfinished and untested
> prototype FindOrocosOCL.cmake I was working on to see what I mean
> (attached). Anyway. Your implementation is a lot more complete.
>
> - Could we rename OROCOS-RTT_INCLUDES to OROCOS-RTT_INCLUDE_DIRS, and
> OROCOS-RTT_LIBS to OROCOS-RTT_LIBRARIES, ... so that the names are more
> standard? or do we want to maintain backwards-compatibility with the current
> naming?
Another mistake. I'll do the rename.
>
>>
>> Peter
>>
>> PS: I used the FindPackageHandleStandardArgs macro instead of the
>> LibFindMacros, in order to have no dependencies in FindOrocos-RTT and
>> FindOrocos-OCL.
>
> Great! I think that since variable names are in uppercase we should abolish
> the nonstandard LibFindMacros. To this end, I'm attaching a slightly
> modified FindXerces.cmake that now uses FindPackageHandleStandardArgs. If
> you like it, we can work on bringing up to speed the other scripts.
You forgot to make the variables cached ? As such mark_as_advanced has
no effect because they don't show up in the GUI (should they??).
Peter
New find macros for Orocos RTT/OCL and user components
2009/6/23 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
> On Tue, Jun 23, 2009 at 10:47 AM, Peter Soetens <peter [dot] soetens [..] ...>
>> Feedback/patches warmly welcome. I've put it in svn under
>> https://svn.mech.kuleuven.be/repos/orocos/orocos-apps/quicky
>
> Looks very good!
>
> A couple of comments:
>
> - What happended to pkgconfig? If you still plan on using it there's the
> FindPkgConfig.cmake standard module that provides functionality for parsing
> pkgconfig files. Never used it, though.
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPkgConfig
I don't need it. We only emit the .pc files during installation (for
other build systems to use), but we don't use them ourselves.
>
> - I didn't see any checks for external dependencies (Boost, curses, ...)
These finds are for user code. If the user requires specific boost
stuff, he needs to use FindBoost himself. We assume that once
Orocos-RTT/Orocos-OCL got installed, all its dependencies are fine
too. I'm not checking for libc either :-)
>
> - There is a specific cmake operator for comparing version numbers:
> if(version1 VERSION_LESS version2). It's documented at the end of the if
> command http://www.cmake.org/cmake/help/cmake2.6docs.html#command:if
Oops I intended to use that but got sloppy.
>
> Also, you might be interested in using the VERSION EXACT invocation of
> find_package. Check out the attached EnforceVersion.cmake script. It does
> just that :)
Nice ! will use.
>
> - I'd define the cmake variables containing the libs, headers, etc. (e.g.,
> OROCOS-RTT_INCLUDES, OROCOS-RTT_LIBS,... ) _after_
> FindPackageHandleStandardArgs has returned, and _only_ if it succeeded, so
> that they are empty if the find process failed. This way we won't end up
> with half-baked variables.
OK. I didn't intend to emit OROCOS-RTT_LIBRARY_DIRS but only
OROCOS-RTT_LIBRARIES.
> You can check out an unfinished and untested
> prototype FindOrocosOCL.cmake I was working on to see what I mean
> (attached). Anyway. Your implementation is a lot more complete.
>
> - Could we rename OROCOS-RTT_INCLUDES to OROCOS-RTT_INCLUDE_DIRS, and
> OROCOS-RTT_LIBS to OROCOS-RTT_LIBRARIES, ... so that the names are more
> standard? or do we want to maintain backwards-compatibility with the current
> naming?
Another mistake. I'll do the rename.
>
>>
>> Peter
>>
>> PS: I used the FindPackageHandleStandardArgs macro instead of the
>> LibFindMacros, in order to have no dependencies in FindOrocos-RTT and
>> FindOrocos-OCL.
>
> Great! I think that since variable names are in uppercase we should abolish
> the nonstandard LibFindMacros. To this end, I'm attaching a slightly
> modified FindXerces.cmake that now uses FindPackageHandleStandardArgs. If
> you like it, we can work on bringing up to speed the other scripts.
You forgot to make the variables cached ? As such mark_as_advanced has
no effect because they don't show up in the GUI (should they??).
Peter
New find macros for Orocos RTT/OCL and user components
2009/6/24 Peter Soetens <peter [dot] soetens [..] ...>
> 2009/6/23 Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...>:
> > On Tue, Jun 23, 2009 at 10:47 AM, Peter Soetens <peter [dot] soetens [..] ...
> >
> >> Feedback/patches warmly welcome. I've put it in svn under
> >> https://svn.mech.kuleuven.be/repos/orocos/orocos-apps/quicky
> >
> > Looks very good!
> >
> > A couple of comments:
> >
> > - What happended to pkgconfig? If you still plan on using it there's the
> > FindPkgConfig.cmake standard module that provides functionality for
> parsing
> > pkgconfig files. Never used it, though.
> > http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPkgConfig
>
> I don't need it. We only emit the .pc files during installation (for
> other build systems to use), but we don't use them ourselves.
>
> >
> > - I didn't see any checks for external dependencies (Boost, curses, ...)
>
> These finds are for user code. If the user requires specific boost
> stuff, he needs to use FindBoost himself. We assume that once
> Orocos-RTT/Orocos-OCL got installed, all its dependencies are fine
> too. I'm not checking for libc either :-)
OK. But say you use CPack to generate a simple binary distribution like tgz
that does not do dependency checking like debs or rpms, and you unpack
Orocos in a different box. Wouldn't you as a user need to check that the new
box has the shared libs Orocos depends on (and the correct versions)?. Or is
this not a point to worry, since Orocos binaries will be distributed in the
form of deb/rpm packages that do that for you anyway...
> >
> > - There is a specific cmake operator for comparing version numbers:
> > if(version1 VERSION_LESS version2). It's documented at the end of the if
> > command http://www.cmake.org/cmake/help/cmake2.6docs.html#command:if
>
> Oops I intended to use that but got sloppy.
>
> >
> > Also, you might be interested in using the VERSION EXACT invocation of
> > find_package. Check out the attached EnforceVersion.cmake script. It does
> > just that :)
>
> Nice ! will use.
>
> >
> > - I'd define the cmake variables containing the libs, headers, etc.
> (e.g.,
> > OROCOS-RTT_INCLUDES, OROCOS-RTT_LIBS,... ) _after_
> > FindPackageHandleStandardArgs has returned, and _only_ if it succeeded,
> so
> > that they are empty if the find process failed. This way we won't end up
> > with half-baked variables.
>
> OK. I didn't intend to emit OROCOS-RTT_LIBRARY_DIRS but only
> OROCOS-RTT_LIBRARIES.
Ack, *_LIBRARY_DIRS is seldom used anyway
>
>
> > You can check out an unfinished and untested
> > prototype FindOrocosOCL.cmake I was working on to see what I mean
> > (attached). Anyway. Your implementation is a lot more complete.
> >
> > - Could we rename OROCOS-RTT_INCLUDES to OROCOS-RTT_INCLUDE_DIRS, and
> > OROCOS-RTT_LIBS to OROCOS-RTT_LIBRARIES, ... so that the names are more
> > standard? or do we want to maintain backwards-compatibility with the
> current
> > naming?
>
> Another mistake. I'll do the rename.
>
> >
> >>
> >> Peter
> >>
> >> PS: I used the FindPackageHandleStandardArgs macro instead of the
> >> LibFindMacros, in order to have no dependencies in FindOrocos-RTT and
> >> FindOrocos-OCL.
> >
> > Great! I think that since variable names are in uppercase we should
> abolish
> > the nonstandard LibFindMacros. To this end, I'm attaching a slightly
> > modified FindXerces.cmake that now uses FindPackageHandleStandardArgs. If
> > you like it, we can work on bringing up to speed the other scripts.
>
> You forgot to make the variables cached ? As such mark_as_advanced has
> no effect because they don't show up in the GUI (should they??).
The output of find_path, find_library, and find_program are always
(non-advanced) cmake cache variables
>
>
> Peter
>
New find macros for Orocos RTT/OCL and user components
2009/6/24 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>> > - I didn't see any checks for external dependencies (Boost, curses, ...)
>>
>> These finds are for user code. If the user requires specific boost
>> stuff, he needs to use FindBoost himself. We assume that once
>> Orocos-RTT/Orocos-OCL got installed, all its dependencies are fine
>> too. I'm not checking for libc either :-)
>
>
> OK. But say you use CPack to generate a simple binary distribution like tgz
> that does not do dependency checking like debs or rpms, and you unpack
> Orocos in a different box. Wouldn't you as a user need to check that the new
> box has the shared libs Orocos depends on (and the correct versions)?. Or is
> this not a point to worry, since Orocos binaries will be distributed in the
> form of deb/rpm packages that do that for you anyway...
I won't scan for broken libraries/installs. That's an endless road in
my opinion.
If someone copies over the installed orocos libs and headers to
another system, without, say,
the libstdc++ or boost headers, that's really his problem.
Anyway, thanks for reviewing this, here's quicky-1.1.
Peter
Some minor fixes for
Some minor fixes for install in non-standard location (Mac OS X Leopard with CMake 2.6.4 under MacPorts portfiles install)
# Appending "." to CMAKE_MODULE_PATH made CMake look in the binary dir, not the source dir.
# Need include directories to be set
# Without the else clause, the user gets a failure later in the CMake file from which it is not apparent that the include file not being found was the issue.
Also attaching a deployer xml file to ease testing the resultant library.
For this to work, I simply had to do the following in the shell
export CMAKE_PREFIX_PATH=/opt/local
Stephen
Some minor fixes for
On Sat, Jul 4, 2009 at 18:20, <kiwi [dot] net [..] ...> wrote:
> Some minor fixes for install in non-standard location (Mac OS X Leopard with
> CMake 2.6.4 under MacPorts portfiles install) # Appending "." to
> CMAKE_MODULE_PATH made CMake look in the binary dir, not the source dir.
> # Need include directories to be set
> # Without the else clause, the user gets a failure later in the CMake file
> from which it is not apparent that the include file not being found was the
> issue.
>
> Also attaching a deployer xml file to ease testing the resultant library.
>
> For this to work, I simply had to do the following in the shell
>
Great! Thanks, applied it.
Peter
New find macros for Orocos RTT/OCL and user components
2009/6/24 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>> > - I didn't see any checks for external dependencies (Boost, curses, ...)
>>
>> These finds are for user code. If the user requires specific boost
>> stuff, he needs to use FindBoost himself. We assume that once
>> Orocos-RTT/Orocos-OCL got installed, all its dependencies are fine
>> too. I'm not checking for libc either :-)
>
>
> OK. But say you use CPack to generate a simple binary distribution like tgz
> that does not do dependency checking like debs or rpms, and you unpack
> Orocos in a different box. Wouldn't you as a user need to check that the new
> box has the shared libs Orocos depends on (and the correct versions)?. Or is
> this not a point to worry, since Orocos binaries will be distributed in the
> form of deb/rpm packages that do that for you anyway...
I won't scan for broken libraries/installs. That's an endless road in
my opinion.
If someone copies over the installed orocos libs and headers to
another system, without, say,
the libstdc++ or boost headers, that's really his problem.
Anyway, thanks for reviewing this, here's quicky-1.1.
Peter
Some minor fixes for
Some minor fixes for install in non-standard location (Mac OS X Leopard with CMake 2.6.4 under MacPorts portfiles install)
# Appending "." to CMAKE_MODULE_PATH made CMake look in the binary dir, not the source dir.
# Need include directories to be set
# Without the else clause, the user gets a failure later in the CMake file from which it is not apparent that the include file not being found was the issue.
Also attaching a deployer xml file to ease testing the resultant library.
For this to work, I simply had to do the following in the shell
Stephen