On Fri, Dec 4, 2015 at 7:24 AM, Jonathan Wakely <jwak...@redhat.com> wrote:
> 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). > Those are valid points. I will contact upstream and see what their thoughts are.
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
