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