When compiling fmt by the direct CMake add_subdirectory(fmt) method (as recommended in the docs), the fmt build inherits the same compilation flags as the project including it.
But it fails for various errors/warnings, in clang at least.
For example missing-noreturn, signed-enum-bitfield, and documentation-unknown-command:
In file included from /fmt/include/fmt/format.h:48:
/fmt/include/fmt/core.h:451:5: error: unknown command tag name [-Werror,-Wdocumentation-unknown-command]
\rst
^~~~
/fmt/include/fmt/core.h:604:38: error: function 'on_error' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]
void on_error(const char* message) { throw_format_error(message); }
^
/fmt/include/fmt/core.h:2075:9: error: enums in the Microsoft ABI are signed integers by default; consider giving the enum type an unsigned underlying type to make this code portable [-Werror,-Wsigned-enum-bitfield]
align(align::none),
^
There were more instances than the above, but this gives the idea.
From my perspective, users of fmt would normally consider it a system include, not a regular part of their codebase. So I suggest that for the target_include_directories() in fmt/CMakeLists.txt, the SYSTEM cmake attribute be used, or at least a CMake OPTION be available to do so.
When compiling
fmtby the direct CMakeadd_subdirectory(fmt)method (as recommended in the docs), thefmtbuild inherits the same compilation flags as the project including it.But it fails for various errors/warnings, in
clangat least.For example
missing-noreturn,signed-enum-bitfield, anddocumentation-unknown-command:There were more instances than the above, but this gives the idea.
From my perspective, users of
fmtwould normally consider it a system include, not a regular part of their codebase. So I suggest that for thetarget_include_directories()infmt/CMakeLists.txt, theSYSTEMcmake attribute be used, or at least a CMakeOPTIONbe available to do so.