OpenImageIO
OpenImageIO copied to clipboard
Raise C++ standard minimmum to C++17 for OIIO 3.0
Raise our C++ standard to C++17 minimum (from 14).
This also includes bumping all of the compilers we support to have whatever minimum versions are necessary to fully support C++17 (we think this means gcc 9.3, clang 5.0 (or maybe 8.0?), MSVS 2017 / v19.14, icc 19.0).
Note: we should not merge any of these changes until after April 1.
A non-comprehensive list of sub-tasks, not necessarily in order:
### Tasks
- [ ] platform.h -- enforce the new minimums, clean up things that only need to be defined for < 17, wide rename of things like OIIO_CONSTEXPR17 -> constexpr, etc.
- [x] INSTALL.md -- document the new minimums
- [ ] externalpackages.cmake -- are there other places where interaction with other packages can be simplified with C++17
- [x] Raise LibRaw minimum to 0.20 because that's the earliest that will work with C++17
- [x] filesystem.cpp and externalpackage.cmake -- remove all the boost filesystem stuff, just use C++17 std::filesystem
- [ ] Search for `OIIO_CPLUSPLUS_VERSION` and `__cplusplus` through the whole codebase, look for places where we are conditionally selecting code to have separate C++14 or C++17 clauses.
- [ ] Search the whole codebase for the compiler version macros (see platform.h) and remove any conditional compilation of things only needed for old versions like gcc6, etc.
- [x] ci.yml -- remove testing cases of the old compilers or C++ standard.
Food for thought / open questions:
- Should we define OIIO::string_view to BE std::string_view? Or are there still advantages to having our own and we should merely ensure that it implicitly can cast from and to the std one?
- Should any places where we take strings that are obviously file paths also have varieties that directly take a std::filesystem::path?
- Are there uses of std::optional, std::variant, or std::any that we should be using in public APIs?