[Rock-dev] [rock] #422: Base Logger does not show namespace for tasks

[rock]

#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