Currently we use the version of fmt bundled with spdlog. This is fine, unless of course the user wants to use their own version and links to it. This can cause issues since we include fmt via spdlog in our headers but the bundled version of fmt is not guaranteed to be the same version the user links to (especially if using the version fetched via cmake and linking to system fmt).
As far as I can see, we have a few options:
Remove all usages of fmt from malloy (I did a search, there are two, both added by me). I would prefer not to go for this option as it might be useful in the future.
Have malloy depend on fmt and pull it in like we do with spdlog currently, then let the user tell malloy to use the one found by cmake instead. We'd also have to toggle spdlog's external fmt flag
Wait for std::format to become supported by the main three. This is unlikely to be soon, afaik only msvc has support for it right now.
Personally I like option (2) best, but I am biased as I love fmt :p
Currently we use the version of fmt bundled with
spdlog
. This is fine, unless of course the user wants to use their own version and links to it. This can cause issues since we include fmt via spdlog in our headers but the bundled version of fmt is not guaranteed to be the same version the user links to (especially if using the version fetched via cmake and linking to system fmt).As far as I can see, we have a few options:
malloy
(I did a search, there are two, both added by me). I would prefer not to go for this option as it might be useful in the future.spdlog
currently, then let the user tell malloy to use the one found by cmake instead. We'd also have to togglespdlog
's external fmt flagstd::format
to become supported by the main three. This is unlikely to be soon, afaik only msvc has support for it right now.Personally I like option (2) best, but I am biased as I love
fmt
:p