The original `InetPton` expands to `InetPtonW` when building with UNICODE defined and expects the string parameter to be wchar_t. On the other hand macro `TEXT()` just adds prefix `L` to a string literal (just making it wchar_t literal). The proper way here would be converting `host.c_str()` result from UTF-8(?) into wchar_t (UNICODE) string, but this seems to be an overkill since the host is typically an IP address or a host/domain name. So assuming an ASCII input should be reasonably safe.
The cmake/spdlogConfig.cmake.in file properly takes into account the fmt
package dependency when building with SPDLOG_FMT_EXTERNAL:BOOL=ON but
not when built with SPDLOG_FMT_EXTERNAL_HO:BOOL=ON.
Prior to these changes SPDLOG_FMT_EXTERNAL_HO:BOOL=ON results in
exported targets with INTERFACE_LINK_LIBRARIES that contain
fmt::fmt-header-only.
As such, the installed spdlogConfig.cmake file should attempt to find
that dependency for the consumer.
Fix `Wreorder-ctor` warning
```
spdlog/pattern_formatter-inl.h:1028:7: error: field 'custom_handlers_' will be initialized after field 'need_localtime_' [-Werror,-Wreorder-ctor]
, custom_handlers_(std::move(custom_user_flags))
^
```
Move the initialization of `need_localtime_(true)` right after `pattern_time_type_` as expected.
spdlog::level::level_enum cannot be forward-declared at present, as
the definition does not specify an underlying type.
To allow users to make use of <spdlog/fwd.h> to refer to
level::level_enum without pulling in all of <spdlog/common.h> (which
can be quite costly), specify an underlying type (int) for
level::level_enum, then add a forward-declaration for it to
spdlog/fwd.h.
Note this required explicitly casting level_enum to size_t within ansicolor_sink due to sign-conversion errors:
implicit conversion changes signedness: 'const level::level_enum' to 'std::__1::array::size_type' (aka 'unsigned long') [-Wsign-conversion]
It would appear that an enum with an unspecified underlying type is in
some kind of superposition - it can be treated as both signed _and_
unsigned - using an underlying type of 'unsigned int' triggers even
more warnings of this kind...
