Make it possible to use objects and collections with fmtlib

[tmadlener]

BEGINRELEASENOTES

• Make it possible to use objects and collections with fmtlib by using the ostream_formatter adaptor from fmtlib.
• fmtlib is now a transitive dependency of podio, i.e. EDMs generated with podio will also depend on it. The necessary propagation of this dependency via CMake is handled here, but build environments might need adjustments.

ENDRELEASENOTES

This is an intermediate step towards better support for using fmt::format (and eventually hopefully also std::format). Currently this simply re-uses the existing operator<<. In a next step I will implement proper formatting via the customization points that fmtlib provides. Then operator<< will be implemented in terms of fmt::format. Ideally, that step would be compatible with <format> in which case we might be able do drop the fmtlib dependency.

See also the discussion in #920 (comment)

[m-fila]

Would it be possible to define std::formater to internally use fmt::formatter, so the users can still use std::format as an entrypoint, and we can still use missing features?

I briefly tried to add std::formatter for datatypes and collections when we moved to C++20 but it seemed not very practical without being able to format ranges (added in C++23)

[tmadlener]

Would it be possible to define std::formater to internally use fmt::formatter, so the users can still use std::format as an entrypoint, and we can still use missing features?

Is that possible on a technical level? 🤔 I hadn't thought about that, but I am trying to actually implement the whole thing now and so far I haven't seen anything that is not yet possible with <format>. The main use for fmt-lib features so far seem to be the fmt::println calls in things adjacent to podio-dump-tool. For that we can very easily make a polyfill for std::printlin and then we might be able to get rid of fmt-lib completely at the end of this.

[m-fila]

Is that possible on a technical level? 🤔

I thought it could be done by adapting the contexts, but couldn't find anyone actually doing this, so perhaps it's not the greatest idea. Never mind

[jmcarcell]

My only comment would be that these tests are not very demanding but having to deal with multiline strings is a bit annoying.

[tmadlener]

Yeah, they basically make sure things compile, not whether they make sense from an output point of view. We didn't have too many for operator<< either, apart from the ones in https://github.com/AIDASoft/podio/blob/master/tests/ostream_operator.cpp which also essentially make sure things compile and don't crash at runtime, but do not make any checks on the outputs themselves.