PR on the GRISU symbol issue: https://github.com/OpenImageIO/oiio/pull/2501 <https://github.com/OpenImageIO/oiio/pull/2501>
> On Feb 29, 2020, at 9:53 AM, Larry Gritz <l...@larrygritz.com> wrote: > > Hi, sorry for the delay in responding. > > I guess as fmt becomes more widely used, things like this could be an issue. > > Unfortunately, we do purposely expose fmt's headers because we have many API > calls that are implemented as templates that themselves call fmt templates, > and therefore they need to be all inline in our headers. I dunno, maybe C++20 > modules will make a way to address this, but we're a long way from being able > to rely on that. > > Well, one thing that seems obvious to do is to change > > #define FMT_USE_GRISU 1 > > to > > #ifndef FMT_USE_GRISU > #define FMT_USE_GRISU 1 > #endif > > I don't think that trying to change the namespace will be helpful or > necessary, because if you look in the fmt headers, they already have an inner > namespace that is versioned. In other words, fmt::v6 in mine vs fmt::v5 in > yours, so presumably it should not have any actual symbol clashes. > > But the header guards are tricky. If there is a module that needs format.h > (say) on its own to use fmt, and also needs OpenImageIO/strutil.h (because it > uses fmt), there can be a funny conflict. Even though yours might want v5 and > mine might want v6, there is no way to include both because of the header > guards. > > It would be a particular problem if yours comes first and only needs format.h > (which includes core.h), but mine needed format.h, ostream.h, and printf.h. > So what happens is that mine asks for format.h, and the header guards think > "I already saw this." Fine, so far. But then it asks for ostream.h, finds it, > but it is referring to the wrong inner namespace v6 for the things in > format.h or core.h, say. > > I can think of a few strategies for addressing this, in addition to the GRISU > fix I described above. > > Does the following work? > > * Always include the OIIO includes *first*? > > or > > * Before including either OIIO or your other things, you do a preemptive > #include <fmt/format.h> > #include <fmt/ostream.h> > ... include all other fmt headers used by either package... > > That would "seed" all the fmt stuff independent of either package and be > uniform. > > or > > * Upgrade your other use to the newer matching fmt. > > Note that only in fairly new fmt versions did they completely fix it to be > locale-independent, so if you are using 5.x, you could run into the problems > with that, especially if you are dealing with European locales (as I am > guessing is possible based on your error messages). > > >> On Feb 19, 2020, at 10:32 AM, Alexandre Bléron <alexan...@artineering.io >> <mailto:alexan...@artineering.io>> wrote: >> >> Hello, >> >> We ran into an issue when using OpenImageIO 2.1.9.0 (built and installed on >> windows with vcpkg) and our own version of fmt 5.3.0 >> (https://github.com/fmtlib/fmt <https://github.com/fmtlib/fmt>) that we use >> within our project. Including both <fmt/format.h> and >> <OpenImageIO/imagecache.h> (possibly the same issue with other headers) will >> result in the following compilation errors (sorry, the output is in french, >> but a rough summary is provided below): >> >> OpenImageIO/strutil.h(44,1): warning C4005: 'FMT_USE_GRISU' : redéfinition >> de macro (compilation du fichier source src\ui\renderoutputview.cpp) >> ext\fmt-5.3.0\include\fmt\format.h(165): message : voir la définition >> précédente de 'FMT_USE_GRISU' (compilation du fichier source >> src\ui\renderoutputview.cpp) >> OpenImageIO\fmt/ostream.h(22,9): error C2059: erreur de syntaxe : '<' >> (compilation du fichier source src\ui\renderoutputview.cpp) >> OpenImageIO\fmt/ostream.h(22,1): error C2238: jetons inattendus avant ';' >> (compilation du fichier source src\ui\renderoutputview.cpp) >> OpenImageIO\fmt/ostream.h(25,19): error C2143: erreur de syntaxe : absence >> de ')' avant '<' (compilation du fichier source src\ui\renderoutputview.cpp) >> OpenImageIO\fmt/ostream.h(25,19): error C2143: erreur de syntaxe : absence >> de ';' avant '<' (compilation du fichier source src\ui\renderoutputview.cpp) >> OpenImageIO\fmt/ostream.h(25,1): error C2059: erreur de syntaxe : '<' >> (compilation du fichier source src\ui\renderoutputview.cpp) >> OpenImageIO\fmt/ostream.h(25,1): error C2059: erreur de syntaxe : ')' >> (compilation du fichier source src\ui\renderoutputview.cpp) >> OpenImageIO\fmt/ostream.h(25,1): error C2334: jetons inattendus avant ':' ; >> corps apparent de la fonction ignoré (compilation du fichier source >> src\ui\renderoutputview.cpp) >> >> ... which basically warns about a macro redefinition (FMT_USE_GRISU) and a >> bunch of syntax errors in OpenImageIO\fmt/ostream.h. The problem is that in >> this compilation unit, our own copy of fmt/format.h is included first (at >> version 5.3.0) and conflicts with the version bundled by OpenImageIO (in >> this case, OpenImageIO/fmt/ostream.h includes OpenImageIO/fmt/format.h, but >> the header guard FMT_FORMAT_H_ has already been set by our own copy which is >> at an incompatible version). >> >> A simple workaround would be to match the two versions of fmt, or maybe to >> set OIIO_USE_FMT=0. However, my question was if fmt was supposed to be >> exposed in the public API of OpenImageIO in the first place, or if it is >> just an implementation detail that should not be visible. In the former >> case, we would need to ensure that either a single version of fmt is used by >> both OpenImageIO and our project, or that both versions are the same (which >> unfortunately is not that easy when pulling the package from an external >> source like vcpkg). >> >> In any case, I'm not sure this is an issue of OpenImageIO per se, but rather >> a general issue of dependency management in C++. Might there be a way to >> somehow avoid such conflicts in the future? Possibly by not exposing the fmt >> headers in the public headers of OIIO, or, if not possible (because of e.g. >> templates) rename the "fmt::" namespace of the copy of fmt used by OIIO to >> something like "oiio_fmt::"? (this would not fix the header guard issue >> though). >> >> Regards, >> >> Alexandre Bléron >> >> artineering.io <http://artineering.io/> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > l...@larrygritz.com <mailto:l...@larrygritz.com> > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz l...@larrygritz.com
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
