[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 Alexander.Duda):

 Replying to [comment:4 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
 What make you think I am mixing the logging facilities?. I was only
 talking about logging on the application-level (base/types(/logger) and
 glog).

 >
 > 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?

 I agree on having a common workflow to simplify things. But we should also
 keep in mind that  we are not developing all libraries by our self but
 integrating them into rock. Therefore, we will always have to deal with at
 least the most common logging and testing framework. This is also the
 reason why I do not see a problem of promoting more than one solution
 here. You see this obviously a bit different and because I do not really
 care which library at the end is used as long people use logging and
 testing facilities I am fine with just not mentioning glog/gtest etc
 again.

-- 
Ticket URL: <http://rock.opendfki.de/ticket/422#comment:5>
rock <http://rock.opendfki.de>
rock: the robot construction kit