需要建议：将 fmt lib 包含在 header-only 库中是否有意义？
Advice needed: does it make sense to include fmt lib in header-only library?
我目前正在结束用于 grid-based 量子计算的 C++ header-only 模板库的开发，并且我正在考虑替换我几乎在开始时编写的旧日志记录模块。
我知道使用 header-only 库将内容打印到标准输出（和文件）听起来有点奇怪，但我大量使用模板来提高运行时二进制文件的灵活性和效率，因此这个选择。
当前的日志记录模块使用 printf（因为我不喜欢 std::cout 语法）、宏、可变参数宏（##__VA_ARGS__），支持控制台颜色并使用 [= 打印出源中的位置13=], __LINE__ 宏，即既不是现代的也不是类型安全的，但它有效。
用 fmt（或类似的东西）替换它是否有意义，或者我应该尝试对现有的进行现代化改造（即用模板替换可变参数宏，自定义 compile-time string_view 等)?
我希望图书馆“straight-away”工作，也就是说，我希望：
a) 尽可能消除依赖性
b) 在 CMake 中尝试 find_package(fmt) 或 FetchContent 静静地获取它们 - （顺便说一句，是否有针对此行为的通用 CMake“模板”？类似于“find_or_fetch”？）
c) 将 fmt 的基本部分作为 git 子模块放入我的项目中，并包含一个小的 header 文件。
除此之外，我还计划使用 HDF5 库（有或没有 C++ 包装器）。
在这里，我再次不确定如何最好地处理它以使集成尽可能无缝，我也没有决定应该使用哪个包装器。
“find_or_fetch”范式是否适合 header-only 图书馆？
如果我是你，我不会。
- A header-only 库意味着极简主义。
fmt 与此相反。
- 一个header-only库意味着user-friendly。强行依赖用户不是很友好。
- 如果您已经走了那么远而不需要更好的日志记录工具，很可能您正在使用的工具已经足够好了。
- 必须匹配格式字符串和参数是不使用
fmt 的最大缺点之一。但是您已经完成了匹配。只要格式字符串是文字，现代编译器就会警告任何不匹配。
如果您进行大量格式化和 {fmt} is designed to support easy embedding. In particular, it has zero dependencies and is relatively small with the minimal configuration consisting of just three moderate-size files. There are several projects that embed {fmt}, for example, spdlog，这是有意义的。与推出自己的格式化解决方案相比，优势在于将来可以轻松移植到 std::format。
我目前正在结束用于 grid-based 量子计算的 C++ header-only 模板库的开发，并且我正在考虑替换我几乎在开始时编写的旧日志记录模块。
我知道使用 header-only 库将内容打印到标准输出（和文件）听起来有点奇怪，但我大量使用模板来提高运行时二进制文件的灵活性和效率，因此这个选择。
当前的日志记录模块使用 printf（因为我不喜欢 std::cout 语法）、宏、可变参数宏（##__VA_ARGS__），支持控制台颜色并使用 [= 打印出源中的位置13=], __LINE__ 宏，即既不是现代的也不是类型安全的，但它有效。
用 fmt（或类似的东西）替换它是否有意义，或者我应该尝试对现有的进行现代化改造（即用模板替换可变参数宏，自定义 compile-time string_view 等)?
我希望图书馆“straight-away”工作，也就是说，我希望：
a) 尽可能消除依赖性
b) 在 CMake 中尝试 find_package(fmt) 或 FetchContent 静静地获取它们 - （顺便说一句，是否有针对此行为的通用 CMake“模板”？类似于“find_or_fetch”？）
c) 将 fmt 的基本部分作为 git 子模块放入我的项目中，并包含一个小的 header 文件。
除此之外，我还计划使用 HDF5 库（有或没有 C++ 包装器）。 在这里，我再次不确定如何最好地处理它以使集成尽可能无缝，我也没有决定应该使用哪个包装器。 “find_or_fetch”范式是否适合 header-only 图书馆？
如果我是你，我不会。
- A header-only 库意味着极简主义。
fmt与此相反。 - 一个header-only库意味着user-friendly。强行依赖用户不是很友好。
- 如果您已经走了那么远而不需要更好的日志记录工具，很可能您正在使用的工具已经足够好了。
- 必须匹配格式字符串和参数是不使用
fmt的最大缺点之一。但是您已经完成了匹配。只要格式字符串是文字，现代编译器就会警告任何不匹配。
如果您进行大量格式化和 {fmt} is designed to support easy embedding. In particular, it has zero dependencies and is relatively small with the minimal configuration consisting of just three moderate-size files. There are several projects that embed {fmt}, for example, spdlog，这是有意义的。与推出自己的格式化解决方案相比，优势在于将来可以轻松移植到 std::format。