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