log4cpp in a non-Orocos environment

We've standardized our C++ logging around log4cpp. It works well for
library code and integrates nicely with OCL::Logging. We've also
started organizing our code such that "utility" functions are separated
into their own libraries so many packages can use them. An example of
this is our log4cpp helper class that let's developers focus on writing
log messages and not setting up logging infrastructure options.

This all works really well when Orocos is installed.

But, we've also got use cases for when only ROS is installed (like just
our Robonaut Gazebo sim). Some of those "ROS-only" packages also use
log4cpp and that log4cpp helper class. But, when Orocos isn't
installed, the helper's manifest.xml call to "<depend
package="log4cpp">" fails.

To work around this, I've written a FindLog4cpp.cmake and placed it in
one of our utility packages that gives preference to the Orocos version
of log4cpp (using rospack find) and falls back on the system install of
log4cpp when Orocos is missing. This works well, except that now all
the classes that used to get log4cpp for free because of ROS's
dependency management now need to have their CMakeLists modified to find
the log4cpp package, include its headers and link to its libraries. Yuck.

There's a better way right? Like a mechanism for adding a "depends"
call in the manifest that falls back on a "rosdep"?

log4cpp in a non-Orocos environment

Op vrijdag 14 september 2012 schreef Dustin Gooding (
dustin [dot] r [dot] gooding [..] ...) het volgende:

> On 09/14/2012 11:02 AM, Peter Soetens wrote:
>
>> Hi Dustin,
>>
>> On Fri, Sep 14, 2012 at 5:02 PM, Dustin Gooding
>> <dustin [dot] r [dot] gooding [..] ...> wrote:
>>
>>> We've standardized our C++ logging around log4cpp. It works well for
>>> library code and integrates nicely with OCL::Logging. We've also started
>>> organizing our code such that "utility" functions are separated into
>>> their
>>> own libraries so many packages can use them. An example of this is our
>>> log4cpp helper class that let's developers focus on writing log messages
>>> and
>>> not setting up logging infrastructure options.
>>>
>>> This all works really well when Orocos is installed.
>>>
>>> But, we've also got use cases for when only ROS is installed (like just
>>> our
>>> Robonaut Gazebo sim). Some of those "ROS-only" packages also use log4cpp
>>> and that log4cpp helper class. But, when Orocos isn't installed, the
>>> helper's manifest.xml call to "<depend package="log4cpp">" fails.
>>>
>>> To work around this, I've written a FindLog4cpp.cmake and placed it in
>>> one
>>> of our utility packages that gives preference to the Orocos version of
>>> log4cpp (using rospack find) and falls back on the system install of
>>> log4cpp
>>> when Orocos is missing. This works well, except that now all the classes
>>> that used to get log4cpp for free because of ROS's dependency management
>>> now
>>> need to have their CMakeLists modified to find the log4cpp package,
>>> include
>>> its headers and link to its libraries. Yuck.
>>>
>>> There's a better way right? Like a mechanism for adding a "depends"
>>> call in
>>> the manifest that falls back on a "rosdep"?
>>>
>> Such thing does not exist. Even more, Willow Garage as decided to move
>> away from manifest.xml and use a package.xml file, with new semantics.
>> Your use case is actually the reason for this change... allow to
>> download individual packages when the whole stack is not necessary. So
>> the long term solution is to get also log4cpp on your 'non-orocos'
>> systems and then 'depends' on that package.
>>
>> The Orocos Toolchain log4cpp package is quite stand-alone, so it
>> should be possible to git clone it on your non-orocos systems, in your
>> ROS_ROOT and just rosmake. It will install in ../install though, that
>> is hard-coded.
>>
>> Peter
>>
>
> Hard-coded, or just a CMake variable?
>

Hard coded in both the rosmake Makefile and the manifest.xml. We can't play
nice with all opposite ways...

Peter

log4cpp in a non-Orocos environment

Hi Dustin,

On Fri, Sep 14, 2012 at 5:02 PM, Dustin Gooding
<dustin [dot] r [dot] gooding [..] ...> wrote:
> We've standardized our C++ logging around log4cpp. It works well for
> library code and integrates nicely with OCL::Logging. We've also started
> organizing our code such that "utility" functions are separated into their
> own libraries so many packages can use them. An example of this is our
> log4cpp helper class that let's developers focus on writing log messages and
> not setting up logging infrastructure options.
>
> This all works really well when Orocos is installed.
>
> But, we've also got use cases for when only ROS is installed (like just our
> Robonaut Gazebo sim). Some of those "ROS-only" packages also use log4cpp
> and that log4cpp helper class. But, when Orocos isn't installed, the
> helper's manifest.xml call to "<depend package="log4cpp">" fails.
>
> To work around this, I've written a FindLog4cpp.cmake and placed it in one
> of our utility packages that gives preference to the Orocos version of
> log4cpp (using rospack find) and falls back on the system install of log4cpp
> when Orocos is missing. This works well, except that now all the classes
> that used to get log4cpp for free because of ROS's dependency management now
> need to have their CMakeLists modified to find the log4cpp package, include
> its headers and link to its libraries. Yuck.
>
> There's a better way right? Like a mechanism for adding a "depends" call in
> the manifest that falls back on a "rosdep"?

Such thing does not exist. Even more, Willow Garage as decided to move
away from manifest.xml and use a package.xml file, with new semantics.
Your use case is actually the reason for this change... allow to
download individual packages when the whole stack is not necessary. So
the long term solution is to get also log4cpp on your 'non-orocos'
systems and then 'depends' on that package.

The Orocos Toolchain log4cpp package is quite stand-alone, so it
should be possible to git clone it on your non-orocos systems, in your
ROS_ROOT and just rosmake. It will install in ../install though, that
is hard-coded.

Peter

log4cpp in a non-Orocos environment

On 09/14/2012 11:02 AM, Peter Soetens wrote:
> Hi Dustin,
>
> On Fri, Sep 14, 2012 at 5:02 PM, Dustin Gooding
> <dustin [dot] r [dot] gooding [..] ...> wrote:
>> We've standardized our C++ logging around log4cpp. It works well for
>> library code and integrates nicely with OCL::Logging. We've also started
>> organizing our code such that "utility" functions are separated into their
>> own libraries so many packages can use them. An example of this is our
>> log4cpp helper class that let's developers focus on writing log messages and
>> not setting up logging infrastructure options.
>>
>> This all works really well when Orocos is installed.
>>
>> But, we've also got use cases for when only ROS is installed (like just our
>> Robonaut Gazebo sim). Some of those "ROS-only" packages also use log4cpp
>> and that log4cpp helper class. But, when Orocos isn't installed, the
>> helper's manifest.xml call to "<depend package="log4cpp">" fails.
>>
>> To work around this, I've written a FindLog4cpp.cmake and placed it in one
>> of our utility packages that gives preference to the Orocos version of
>> log4cpp (using rospack find) and falls back on the system install of log4cpp
>> when Orocos is missing. This works well, except that now all the classes
>> that used to get log4cpp for free because of ROS's dependency management now
>> need to have their CMakeLists modified to find the log4cpp package, include
>> its headers and link to its libraries. Yuck.
>>
>> There's a better way right? Like a mechanism for adding a "depends" call in
>> the manifest that falls back on a "rosdep"?
> Such thing does not exist. Even more, Willow Garage as decided to move
> away from manifest.xml and use a package.xml file, with new semantics.
> Your use case is actually the reason for this change... allow to
> download individual packages when the whole stack is not necessary. So
> the long term solution is to get also log4cpp on your 'non-orocos'
> systems and then 'depends' on that package.
>
> The Orocos Toolchain log4cpp package is quite stand-alone, so it
> should be possible to git clone it on your non-orocos systems, in your
> ROS_ROOT and just rosmake. It will install in ../install though, that
> is hard-coded.
>
> Peter

Hard-coded, or just a CMake variable?