On 03/12/15 13:57 -0700, Dave Johansen wrote:
My hope was to maintain source compatibility and not binary compatibility. For example, the header file moved from: /usr/include/format.h to: /usr/include/cppformat/cppformat.h I was planning on updating the stable release with a symlink at: /usr/include/cppformat/cppformat.h Then code could just #include <cppformat/cppformat.h> for both 2.0 and 1.1. The built binaries will not be compatible and the code would need to use the subset of the API that was uniform or use conditional compilation, but having a consistent place to look for the header should simplify that.
That would cause a problem for code that tries to detect which version is present by doing __has_include(<cppformat/cppformat.h>) and adapting which API it uses according to the result e.g. #ifdef __has_include # if __has_include(<cppformat/cppformat.h>) # include <cppformat/cppformat.h> # define USE_CPPFORMAT2_API # endif #endif #ifndef USE_CPPFORMAT2_API # include <format.h> #endif ... Such code would work with other distros, but not Fedora if you implement your suggestion. I don't know if such code exists, but then I don't know if any code exists that would benefit from the symlinks either. Are there users who would actually make use of the new header location and restrict themselves to the common subset of the API? (And even if they make that effort, it would only work for cppformat 1.1 on Fedora, because other distros wouldn't have the common header location). -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx