[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A GNUNET_log oddity
Re: A GNUNET_log oddity
Tue, 31 Aug 2021 15:41:32 +0200
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Christian Grothoff <firstname.lastname@example.org> writes:
> GNUnet should run on embedded-ish systems, and binary size does
> matter. The idea behind the configure flag is that by default, DEBUG
> messages are never included, and only developers can (and likely will)
> explicitly enable them to aid their diagnosis.
I see, that's a good reason.
> So if you want a message to be possibly visible to ordinary users,
> formulate it nicely and log at INFO level. DEBUG messages are, as the
> name says, for debugging, and that's not something normal users should
> have to do ;-).
Well, the thing is, since GNUnet pre-populates both services' and
clients' set of recognized command line flags with the option to specify
a log file and a log level, it would make sense for a developer to use
this infrastructure for its own debug messages, instead of writing a new
one from scratch.
Being able to let users enable DEBUG-level messages (with or without a
rebuild of the application) is something that can be used to
troubleshoot a difficult bug report, for example.
> As for applications using libgnunetutil, well, they again need to copy
> that mechanism into their configure-scripts, or they won't get
> DEBUG-level logging. I think that's OK. That said, we _may_ be able to
> improve the (developer) handbook documentation on logging on this point.
Then if no one minds, I'm going to flip the value given to
GNUNET_EXTRA_LOGGING when the configure script doesn't define it, from 0
to 1, so that third-party application developers can leverage the full
range of error levels during development (e.g. me, while I test things
out in my application and decide to get swamped by messages only when
something strange happens.) I'm not sure if giving larger values, like
GNUnet does, is meaningful when the goal is to get debug messages. If
even more verbosity is required, developers should probably use their
Scanning the GNUnet core codebase, I can't see any place where that
macro is not defined, so changing the value inside the #ifndef shouldn't
cause any issue for the base installation, only for external programs.
Anyone targeting small embedded systems can then imitate GNUnet by
explicitly setting it to 0 or adding a flag to their build system. I'm
going to add it to the Autoconf macro I commited to the "build-info"