[Rock-dev] [rock] #422: Base Logger does not show namespace for tasks
rock
noreply at opendfki.de
Tue Feb 18 14:43:55 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 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
More information about the Rock-dev
mailing list