Logging to file

[mahesh-hegde]

It would be nice for debugging if the logs from last run of jnigen are all contained in .dart_tool/jnigen/, this also allows to separate logs of CMake, gradle etc.. tools, and let APISummarizer have its own logs. @HosseinYousefi wdyt?

[HosseinYousefi]

It's a good idea, what are some other tools that do this?

[mahesh-hegde]

I think kdesrc, KDE's build system did this. But only if build failed. This was because many tools involved and printing all their logs will be cumbersome, they were put in a directory.

I believe most applications do log something to files on crash. If we don't want these files in happy path, we can delete them.

[mahesh-hegde]

Found this: https://docs.kde.org/trunk5/en/kdesrc-build/kdesrc-build/kdesrc-build-logging.html

[HosseinYousefi]

The reason I'm asking is to use some common way to do this. Logging always vs only on crash. By default or only when provided a flag?

For example, npm logs the full thing to file on crash by default.

[dcharkes]

package:logging has a concept of hierarchy Logger(''), Logger('foo'), Logger('foo.bar'). Maybe we can use that hierarchy to output the logs of different things to different files.

In package:test we have printOnFailure which prints all logs when a test fails but none if the test doesn't fail.
For tests, we can start using that for the prints from the logger. (See https://github.com/dart-lang/native.)
For non-tests, we can build something similar, e.g. the print-message just sends everything to a long buffer, and from the main function we can have a finally that prints all of that if we have an uncaught exception or if we exit with a failure from dart code ourselves.

[mahesh-hegde]

package:logging has a concept of hierarchy Logger(''), Logger('foo'), Logger('foo.bar'). Maybe we can use that hierarchy to output the logs of different things to different files.

We don't really make use of this in jnigen, now. It's a good idea to eventually use that (ffigen does).

OTOH, logs from individual file / classes will be small enough. Where this will be useful is external tools we frequently invoke & summarizer.

In issues like #683 we would benefit from seeing what happened when we invoked gradle.

[mahesh-hegde]

Logging always vs only on crash. By default or only when provided a flag?

By default, because we can ask 'can you paste .dart_tool/jnigen/gradle.log?` on issue reports.

And if you're dumping this file on failure, taking a flag is not very useful way. We can't predict something will fail.

On failure or always?

I think on failure is enough. If you find a wrong binding and want to see logs, you can re-run with -Dlog_level=finest.

I can see CMake storing logs in CMakeFiles/ even in case of success. But this is less essential for locally run tools than web apps in which reproducing problems isn't so simple.

[HosseinYousefi]

One thing I like about combining logs is that I can see the steps in order they happened. So instead of having a jnigen.log and a gradle.log, we could have a single jnigen.log containing all of it that can have a subsection when the failure happened like:

=== Gradle Log Start ===
.
.
.
=== Gradle Log End ===

---

I can understand why k8s does this but JNIgen usually follows a path of execution with a handful of fixed programs being run in a specific order.

[mahesh-hegde]

That's also fine. I don't have an opinion on whether invoked tool logs should go to separate files.

[mahesh-hegde]

While it's nice to save the log file only on failure, we might invoke logging from contexts which do not involve main, such as tests (where it's difficult to determine when to delete the log file). What's a good balance here?