Modularise Olly

[eutro]

This PR splits the single monolithic bin/olly.ml file into several separate libraries, (olly_common, olly_trace, olly_gc_stats), as well as abstracting and modularising the trace formats of olly_trace. Other changes are:

• There is a new Opam package runtime_events_tools_bare which builds the new bin/olly_bare.exe, which depends only on ocaml, dune, and cmdliner (omitting gc-stats and trace --format=fuchsia).
• Minor and hopefully uncontroversial overall changes, that I wanted to make while I was touching the code anyway:
  • trace --format=json now logs custom int (as counter) and unit (as instant) events, as they are with --format=fuchsia
  • The BUGS section now links to http://github.com/tarides/runtime_events_tools/issues, rather than http://bugs.example.org

The benefits are:

• Practically, modularising this way allows for both a minimal build with minimal dependencies, while still allowing a fuller build with all dependencies
  • Olly currently unconditionally depends on tracing, which transitively depends on many other packages, which aren't portable to trunk builds of OCaml, nor to Windows.
    • This could also be "fixed" by either using a different library, rolling our own trace writer, etc., but that would require a much larger behavioural change
  • The minimal build, olly_bare, builds with only dune and cmdliner as dependencies; these can be installed without Opam.
    • For instance, a build of olly_bare on trunk or Windows can be done by just installing OCaml and Dune, then adding cmdliner as a git submodule, and running dune build bin/olly_bare.exe
      • We now know that Olly doesn't currently work on Windows, due to how Unix on Windows handles PIDs (as HANDLEs casted to int), which is incompatible with Runtime_events needing real PIDs; the potential fixes aren't difficult, involving a GetProcessId somewhere (though PIDs should also just be handled better by core OCaml on Windows, it shouldn't be on the user to hack around it, e.g. win32unix: cannot kill and wait for arbitrary processes ocaml/ocaml#11021)
• It is my personal opinion that this is much more maintainable; a single sprawling undocumented OCaml file is unclear. Now we have multiple undocumented OCaml files, but at least they have clear names and intentions.

Potential issues are:

• This is a major change to the structure of the codebase
  • It may be controversial, in whether the changes made are desirable, or sufficiently high quality
  • Outstanding work on Olly would need to be substantially changed to fit the new structure. This should hopefully be simple, the two currently outstanding PRs, for instance, are relatively minor, but there may be other outstanding work that is not a public PR yet.

I am looking for feedback with whether this is desirable overall, as well as with the specific approach I took, since I am largely unexperienced with Dune as a build system, and with OCaml's ecosystem. For instance, the statically-linked minimal-olly_bare/full-olly approach is somewhat unsatisfying due to inflexibility (e.g. to include gc-stats without --format=fuchsia, without changing Olly's code). It may be desirable, perhaps as future work, if the subcommands (and format backends) could instead be loaded dynamically, rather than linked statically.

[kayceesrk]

Thanks @eutro. Do you have a reviewer in mind already?

[eutro]

Thanks @eutro. Do you have a reviewer in mind already?

Thanks; @sadiqj should definitely look at it; otherwise whoever is available.

[tmcgilchrist]

The dependency on tracing is unfortunate, for a fundamental tool like this something lighter would be preferrable. Right now it'll support Linux (x86_64, ARM64), macOS (x86_64, ARM64) and FreeBSD (x86_64) but adding support for other Tier-1 OCaml platforms is difficult. No idea about Windows, that's outside of my knowledge.

For outstanding work, #40 is trivial to update. I started an implementation of #41 for Unix but haven't finished it. How to implement that on Windows I am not sure.

[tmcgilchrist]

The modularity in this change is good @eutro. Not merging so @sadiqj can provide his comments.

My preference for the cli is just have olly and fix the dependencies so they can work on Windows, released versions of the compiler and OCaml trunk.

[sadiqj]

This looks like a nice reorganisation to me, thanks @eutro

With regards to tracing as a dependency, it would be preferable to have something a little lighterweight. @talex5 are you working on something for eio tracing?

[talex5]

eio-trace has its own minimal library for fuchsia support: https://github.com/ocaml-multicore/eio-trace/tree/main/fxt

It does use Eio.Buf_{read,write} for buffered IO, though.