debug logging
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Mon Aug 21 14:09:16 UTC 2023
Hi,
I think adding better debugging capabilities to jextract is definitively
helpful. I agree that right now jextract tends to be on the quiet side.
That said, I think it's important we identify the categories of events
that we are interested in logging. Logging clang parameters might be a
good idea. As for parsing, I'm not too much of a fan of logging every
single parsing event - as that would lead to very very long outputs.
It almost seems like what you are looking for is some way to let
jextract print some more info about what it wanted to do before it
crashed. And I'm sure that this use case is mostly driven by the fact
that you are working to _extend_ jextract as opposed to use it.
If my hunch is correct, I'd say that using a logger to allow for better
debuggability when extending jextract is not the best way to do things.
We should probably instead invest in making exceptions/errors more
meaningful (I often wished I had a way to print the specific piece of C
header we were about to parse when some exception occurred).
And logging should instead be used for user-facing events (e.g. which
headers are being parsed, which symbols are being excluded, which
classes are being written, etc.).
An example of that is this:
> - Sometime you receive "Failed to parse
> /tmp/jextract$1721579888733730008.h:" message, when you try to see
> contents of /tmp/jextract$1721579888733730008.h to understand why it
> is failed the file is already deleted.
This is something a user should never see. E.g. if the user sees it - it
is a bug - and you don't want better logging you (as a jextract user)
just want it to be fixed.
Maurizio
More information about the jextract-dev
mailing list