What is the difference between fmtquill and external fmt, and why is the bundled version needed?

[steve-lorimer]

IIRC you used to support an option QUILL_FMT_EXTERNAL which would allow us to use an external fmtlib, rather than the one bundled with quill.

At some point this option was removed, and now we are required to use the bundled fmtlib, which has been modified to be in the fmtquill namespace.

In my project I am using fmtlib-11.2.0 and quill-10.1.0. The bundled version of fmt in quill is also version 11.2.0.

In an attempt to discover the need for the bundled version, I compared the source code of fmtquill vs fmt. After renaming fmtquill to fmt and FMTQUILL to FMT, I am left with only one meaningful difference.

Namely that the access specifier for buffer has been changed from private to protected

/// A contiguous memory buffer with an optional growing ability. It is an
/// internal class and shouldn't be used directly, only via `memory_buffer`.
template <typename T> class buffer {
protected:                        // <--- in fmtlib this is private
  T* ptr_;
  size_t size_;
  size_t capacity_;

I seem to remember a discussion on reddit where you mentioned that you relied on an internal api of fmtlib in order to facilitate formatting off the critical path.

However, I searched through the codebase to try find something inheriting buffer, and making use of the internals via protected access, and the only class I can find inheriting buffer is basic_memory_buffer, and I do not see any access to the protected internals.

So my question is, why do we need the bundled fmtquill?

I've seen in the cheat sheet how to share formatters between the two.

However, given my investigations, it seems as if they are one-and-the-same.

Would it be feasible to do something like:

namespace fmtquill {

using namespace fmt;

}

or alternatively, have a compile-time option to disable the bundled fmtquill library and specify which namespace to use for formatting?

[odygrd]

Hey, we actually did use that buffer access back in older versions of Quill (around v7.1.0), but you’re right — it’s no longer needed today. https://github.com/odygrd/quill/blob/v7.1.0/include/quill/core/FormatBuffer.h

The main reasons we ship with an internal fmtquill are:

Major reasons

• Performance consistency: Different versions of libfmt have different performance characteristics. Since I run benchmarks before every release, pinning to a specific internal version ensures predictable and repeatable results. Example: fmt issue #4070.
• Maintenance burden: When we supported external libfmt, we had to maintain a lot of #ifdefs to handle API changes across versions (9, 10, 11, etc). That created fragility and ongoing overhead just to keep things compiling.

Minor reasons

• Quill is fully header-only. libfmt can be header-only or compiled as a separate library. Keeping our own version means Quill stays self-contained, independent of how the user configures libfmt.
• libfmt’s header-only mode pulls in everything. Quill only needs a subset for most frontend headers (often just base.h). With the internal version, we can keep includes minimal and compilation lighter. https://github.com/fmtlib/fmt/blob/17be91c07901d960e1ede3c94b286d14129ca868/include/fmt/base.h#L2999
• There are still a few quirks with formatting (e.g. us vs Unicode in chrono → link) that are easier to control when we own the namespace.

I’m not completely against bringing back the external option in the future, but it would require some effort:

• Package managers would need a proper flag to either pull in an external libfmt dependency or not.
• We’d have to reintroduce #ifdef support for multiple libfmt versions (e.g. 9 through 12+) and their internal differences.

For now, the internal fmtquill keeps Quill predictable, and easier to maintain — but I’m open to revisiting this sometime in the future

[steve-lorimer]

Thanks for the detailed response!