Hi Martin, hi Community,
first of all: thanks for all the fish err GREPs! We need to kick off
this discussion.
So, this PR is very dear to my heart, because I consider log4cpp to be
an especially problematic dependency.
And I consider our logging to be subpar considering the size of the
code base, user base and the fact that people are using GNU Radio in
infrastructure for rather expensive things.
So, I took the opportunity (being at 35c3, just to pose around a little
bit) and talked to a couple Osmocom folks. Osmocom people, please
correct me if I make any mistakes.
What they have in osmocore is essentiall logging in both quantized
severity and in categories, and logging routing.
For them, that's very important, as they use that to supply resilient
infrastructure. I hope I'm representing the idea kinda correctly here:
They might want to log system events ("SUPERVISOR: INFO system load
surpassing 75%") somewhere, and development info ("gr-6G: TRACE found a
preamble") on-screen, and critical messages ("gr-digital: FATAL run out
of developer coffee") everywhere.
I want that too. I want this to be easily integratable into software
that uses GNU Radio as library. And if I'm already making wishes here,
I want loggers that interface to modern logging systems, be it
journald, graylog or SNMP. Something.
So, I think that's pretty similar to what UHD does (correct me please,
Martin). I think that UHD is a bit more flexible on the logging
"categories" than I'd like to be, but that really just means we need to
set a convention.
So, I'm stuck wondering whether we adopt the self-implemented system
that UHD uses, or the self-implemented system that osmocore uses, or
implement our own.
Familiarity suggests UHD, maturity osmocore.
Best regards,
Marcus
On Thu, 2018-12-27 at 13:49 -0800, Martin Braun wrote:
> This GREP was recently submitted here:
>
>
https://github.com/gnuradio/greps/blob/master/grep-0013-remove-log4cpp.md
>
> We may or may not go through with this. However, we like to kill
> dependencies (hey there node.js developers :D ), and log4cpp has some
> issues of its own that we're currently inheriting.
>
> Personally, I use GR logging only for debugging purposes. But I know
> that others use it for other reasons, and this thread is a good place
> to discuss:
> - Alternatives to log4cpp (I've listed Boost.Log and hand-spun as
> options)
> - What people need it for
> - Is the current logging in a good shape as it is
> - Who wants to own this task?
> - etc.
>
> Cheers,
> Martin
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
