[Rock-dev] [rock] #422: Base Logger does not show namespace for tasks
rock
noreply at opendfki.de
Tue Feb 18 13:11:21 CET 2014
#422: Base Logger does not show namespace for tasks
---------------------+------------------------------------
Reporter: dmronga | Owner: rock-dev-mailing-list
Type: defect | Status: reopened
Priority: minor | Milestone:
Component: base | Resolution:
Keywords: |
---------------------+------------------------------------
Comment (by sylvain.joyeux):
Replying to [comment:3 Alexander.Duda]:
> I do see your point. Nevertheless, orogen is independent of rock and
therefore should not blindly define preprocessor definitions just for the
case someone wants to use a specific library.
Yes, but could allow for frameworks to "tune" the templates for their own
needs. In other words, we could find a way to fix this bug without
breaking orogen's rock-independence.
> This also the reason why I believe we do not have to put
base/types/logger over glog or vice versa. Logging on the application-
level is optional and should be left to the developer to pick the tool
which fits best to help him debugging and maintaining his code. Rock can
only give a recommendation and I would certainly not recommend to use
base/types/logger if the library is not using base/types like for example
vizkit3d etc.
First, you are mixing the text-based logging from base/types (which is
independent of RTT) and the data-oriented logging of tools/logger
On the choice of logging infrastructure, I don't agree. Part of the point
of Rock is to have common development workflow '''because''' it enables
common tooling '''and''' fosters collaboration. Logging is an important
part of this, same as testing, and we should definitely try to all use the
same implementations. I actually meant to ask your opinion on gtest vs.
boost.test since you have decided to use gtest for your latest library
(gtest seems to win by a small margin when googling it)
Now, this is indeed only a recommendation.
I can only recommend Rock developers to not feel like they can ignore the
recommendations without good reasons, because it *will* make the life of
the other developers miserable. We certainly don't want to have to learn
10 logging frameworks (half of them being self-growned) and 10 testing
frameworks only so that we can start touching the code of any Rock
library, do we ?
--
Ticket URL: <http://rock.opendfki.de/ticket/422#comment:4>
rock <http://rock.opendfki.de>
rock: the robot construction kit
More information about the Rock-dev
mailing list