Skip to content
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

Closed
vitaut opened this issue Apr 20, 2016 · 9 comments
Closed

Improve naming consistency #307

vitaut opened this issue Apr 20, 2016 · 9 comments

Comments

@vitaut
Copy link
Contributor

vitaut commented Apr 20, 2016

The library has been using the fmt namespace and FMT 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 drop cpp 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.

@vitaut
Copy link
Contributor Author

vitaut commented Apr 20, 2016

No collisions on Ubuntu:

> apt-file find /usr/include/fmt
libc6-dev: /usr/include/fmtmsg.h
libowfat-dev: /usr/include/fmt.h
> apt-file find libfmt

@vitaut
Copy link
Contributor Author

vitaut commented Apr 24, 2016

Mostly done, but need to update the docs and scripts.

@vitaut vitaut closed this as completed Apr 28, 2016
@daveisfera
Copy link

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.

@vitaut
Copy link
Contributor Author

vitaut commented May 9, 2016

@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.

@daveisfera
Copy link

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.

@vitaut
Copy link
Contributor Author

vitaut commented May 9, 2016

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.

@vitaut
Copy link
Contributor Author

vitaut commented May 9, 2016

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.

@daveisfera
Copy link

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.

@vitaut
Copy link
Contributor Author

vitaut commented May 15, 2016

Thanks! I'll make sure that the naming conventions remain stable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants