-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve naming consistency #307
Comments
No collisions on Ubuntu:
|
Mostly done, but need to update the docs and scripts. |
Just as a point of feedback, this sorts of dramatic change seem to keep happening and are horrible for users. It makes it really hard to write software that that uses cppformat because some places will have 2.x and others will have 3.x and supporting both becomes very burdensome, or perhaps even impossible, when things like this keep happening. |
@daveisfera Thanks for the feedback and sorry for the breakage. I don't expect the naming to change so dramatically in the future. Also the namespace hasn't changed at all, only the include directory and library name. It should be possible to maintain compatibility with 2.0 via symlinks or wrapper headers (as it is done now). The library name is less of a problem because 3.0 is not binary compatible with 2.0 anyway. |
The problem is that API compatibility is probably even more important than ABI compatibility. Our app is intended to work across several versions of RHEL/CentOS and Fedora and we do a separate build for each, but right now that requires jumping through a bunch of hoops because files libraries seem to keep changing name and location with almost every release. |
The 2.x releases were a bit of a mess, but I think it should be stable from now on. If you have ideas of how to improve compatibility with older releases, please let me know. |
BTW if you are using CMake, it should be possible to do something like: find_library(FMT_LIBRARY NAMES fmt cppformat ...) to handle both 2.x and 3.x. And, as I mentioned, there are compatibility wrappers for the main headers. |
Unfortunately, we don't have CMake for our build system. Also, because of the rename of the .so, I'll probably just release fmt 3.0 for Fedora and EPEL to avoid the different names. |
Thanks! I'll make sure that the naming conventions remain stable. |
The library has been using the
fmt
namespace andFMT
macro prefix since its inception while the library name varied (format, C++ Format, cppformat). It might be a good idea to finally bring the library name in line with the namespace. Also for the forthcoming bindings to other programming languages, it would be nice to dropcpp
from the name. Possible options: FMT, fmt, libfmt.Need to carefully plan this to avoid breaking client code. Perhaps this can be done in version 3.0 together with moving iostreams-related functionality to a separate header to further speed up compilation.
The text was updated successfully, but these errors were encountered: