We're only just now wrapping the last show that uses a software stack based on gcc4.8/C++11. It will probably be a couple more years before we (and everybody else who uses OIIO) are totally free of the need to be compatible with prior years' DCC apps that are gcc6/C++14. As a core library used across many products and apps, we just can't require users to be closer to the bleeding edge than other apps they depend on and need to link against.
I'm hopeful that the ASWF TAC and/or VFX Platform can be urged to give definitive guidance on how many prior years of VFX Platform should continue to be supported by the foundational open source libraries. VFX Platform CY 2021 was the first to be C++17, so if/when we can get a clear sunset date on compatibility with CY 2020, we'll know when we can drop 14. > On Mar 27, 2021, at 1:13 PM, Solomon Boulos <bou...@cs.stanford.edu> wrote: > > Why not make the jump to 17 now? There are a lot of nice bonuses in C++17 ( > https://isocpp.org/files/papers/p0636r0.html > <https://isocpp.org/files/papers/p0636r0.html> is a reasonable summary) and > given how long you’ve been on C++11, it seems like it’d be a while before > upgrading again. Unless you figure you’d do the C++17 upgrade next year? > > On Sat, Mar 27, 2021 at 12:52 Larry Gritz <l...@larrygritz.com > <mailto:l...@larrygritz.com>> wrote: > https://github.com/OpenImageIO/oiio/pull/2918 > <https://github.com/OpenImageIO/oiio/pull/2918> > > This is just testing the waters by changing the *default* compatibility mode > from C++11 to C++14, but not yet dropping support for C++11, to shake > anything loose that will be trouble for people. For now, you can keep > compiling master with C++11 by using -DCMAKE_CXX_STANDARD=11 on the cmake > configure step. > > But the bump of the true minimum to C++14 (and dropping of gcc 4.8 and MSVS > 2015) is IMMINENT. > > For perspective, VFX Platform has specified C++14 since 2018, and specifies > C++17 for 2021. So this is not exactly a bleeding edge move. > > Of course, I'm only talking about master (future OIIO >= 2.3). Compilers, > standards, and other dependencies will never be removed from supported > release branches (currently 2.2). Nothing stops people from using 2.2 if they > need compatibility with older dependencies or build tools. > > I'm also thinking that by the time we release OIIO 2.3, other dependencies > may also have their minimum versions raised. For example, we currently > support OpenEXR as far back as 2.0 (2012!). > > So let this be the final notice -- if you are expecting OIIO 2.3 (not > officially released/supported until the second half of 2021) to be compatible > with gcc 4.8, C++11, MSVS < 2017, or to build against any versions of its > dependencies that are older than 2016, please speak up now and we can discuss > these requirements. > > > -- > Larry Gritz > l...@larrygritz.com <mailto:l...@larrygritz.com> > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > _______________________________________________ > 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
