Don't impose C++14 on downstream projects #995
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We were setting
target_compile_features(${objlib} PUBLIC cxx_std_${OPENEXR_CXX_STANDARD})
The `PUBLIC` forced downstream projects that consume the
`OpenEXRConfig*.cmake` exports to use C++ standard at least as recent
as what OpenEXR used to build (which defaults to 14).
But this is unnecessary. There's nothing in OpenEXR's headers that
requires anything beyond C++11. So this patch uses a more fine-grained
setting of target properties to express this more correctly. Now it will
be fine for a C++11 project to consume OpenEXR (via its exported configs)
even if that OpenEXR happened to be built with C++14.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
|
We'll need to do this on the Imath side, too (I'll submit a PR there after I get feedback here). We'll also want to backport this to the next 3.0 and 2.5 patch releases. |
|
Related: We also have another file, OpenEXRLibraryDefine.cmake, which is subtly different from this LibraryDefine.cmake, but is never called anywhere as far as I can tell. I'm happy to amend this PR to also remove the redundant/useless file, but I want people to diff them and have confidence that we are removing the right one. |
5 tasks
meshula
approved these changes
Apr 4, 2021
| # also use C++14. | ||
| target_compile_features(${objlib} | ||
| PRIVATE cxx_std_${OPENEXR_CXX_STANDARD} | ||
| INTERFACE cxx_std_11 ) |
There was a problem hiding this comment.
i did not know this is possible.
lgritz
added a commit
to lgritz/Imath
that referenced
this pull request
Apr 11, 2021
We were setting
target_compile_features(${objlib} PUBLIC cxx_std_${IMATH_CXX_STANDARD})
The PUBLIC forced downstream projects that consume the
ImathConfig*.cmake exports to use C++ standard at least as recent as
what Imath used to build (which defaults to 14).
But this is unnecessary. There's nothing in Imath's headers that
requires anything beyond C++11. So this patch uses a more fine-grained
setting of target properties to express this more correctly. Now it
will be fine for a C++11 project to consume Imath (via its exported
configs) even if that Imath happened to be built with C++14.
This change is exactly the same as
AcademySoftwareFoundation/openexr#995
Signed-off-by: Larry Gritz lg@larrygritz.com
lgritz
added a commit
to lgritz/Imath
that referenced
this pull request
Apr 11, 2021
We were setting
target_compile_features(${objlib} PUBLIC cxx_std_${IMATH_CXX_STANDARD})
The PUBLIC forced downstream projects that consume the
ImathConfig*.cmake exports to use C++ standard at least as recent as
what Imath used to build (which defaults to 14).
But this is unnecessary. There's nothing in Imath's headers that
requires anything beyond C++11. So this patch uses a more fine-grained
setting of target properties to express this more correctly. Now it
will be fine for a C++11 project to consume Imath (via its exported
configs) even if that Imath happened to be built with C++14.
This change is exactly the same as
AcademySoftwareFoundation/openexr#995
Signed-off-by: Larry Gritz <lg@larrygritz.com>
cary-ilm
pushed a commit
to AcademySoftwareFoundation/Imath
that referenced
this pull request
Apr 16, 2021
We were setting
target_compile_features(${objlib} PUBLIC cxx_std_${IMATH_CXX_STANDARD})
The PUBLIC forced downstream projects that consume the
ImathConfig*.cmake exports to use C++ standard at least as recent as
what Imath used to build (which defaults to 14).
But this is unnecessary. There's nothing in Imath's headers that
requires anything beyond C++11. So this patch uses a more fine-grained
setting of target properties to express this more correctly. Now it
will be fine for a C++11 project to consume Imath (via its exported
configs) even if that Imath happened to be built with C++14.
This change is exactly the same as
AcademySoftwareFoundation/openexr#995
Signed-off-by: Larry Gritz <lg@larrygritz.com>
cary-ilm
pushed a commit
to cary-ilm/openexr
that referenced
this pull request
May 13, 2021
) We were setting target_compile_features(${objlib} PUBLIC cxx_std_${OPENEXR_CXX_STANDARD}) The `PUBLIC` forced downstream projects that consume the `OpenEXRConfig*.cmake` exports to use C++ standard at least as recent as what OpenEXR used to build (which defaults to 14). But this is unnecessary. There's nothing in OpenEXR's headers that requires anything beyond C++11. So this patch uses a more fine-grained setting of target properties to express this more correctly. Now it will be fine for a C++11 project to consume OpenEXR (via its exported configs) even if that OpenEXR happened to be built with C++14. Signed-off-by: Larry Gritz <lg@larrygritz.com>
cary-ilm
pushed a commit
to cary-ilm/Imath
that referenced
this pull request
May 13, 2021
) We were setting target_compile_features(${objlib} PUBLIC cxx_std_${IMATH_CXX_STANDARD}) The PUBLIC forced downstream projects that consume the ImathConfig*.cmake exports to use C++ standard at least as recent as what Imath used to build (which defaults to 14). But this is unnecessary. There's nothing in Imath's headers that requires anything beyond C++11. So this patch uses a more fine-grained setting of target properties to express this more correctly. Now it will be fine for a C++11 project to consume Imath (via its exported configs) even if that Imath happened to be built with C++14. This change is exactly the same as AcademySoftwareFoundation/openexr#995 Signed-off-by: Larry Gritz <lg@larrygritz.com>
cary-ilm
added a commit
to AcademySoftwareFoundation/Imath
that referenced
this pull request
May 16, 2021
* Lib version (#133) * Expose IMATH_LIB_VERSION_STRING, for easier diagnostics Expose the IMATH_LIB_VERSION as a cpp define, along with IMATH_VERSION, to aid in confirming what SOCURRENT.SOAGE.SOVERSION the library is built with. Signed-off-by: Cary Phillips <cary@ilm.com> * Add comment explaining IMATH_LIB_VERSION Signed-off-by: Cary Phillips <cary@ilm.com> * Add section on python bindings (#135) Signed-off-by: Cary Phillips <cary@ilm.com> * Don't impose C++14 on downstream projects (#137) We were setting target_compile_features(${objlib} PUBLIC cxx_std_${IMATH_CXX_STANDARD}) The PUBLIC forced downstream projects that consume the ImathConfig*.cmake exports to use C++ standard at least as recent as what Imath used to build (which defaults to 14). But this is unnecessary. There's nothing in Imath's headers that requires anything beyond C++11. So this patch uses a more fine-grained setting of target properties to express this more correctly. Now it will be fine for a C++11 project to consume Imath (via its exported configs) even if that Imath happened to be built with C++14. This change is exactly the same as AcademySoftwareFoundation/openexr#995 Signed-off-by: Larry Gritz <lg@larrygritz.com> * Fix regression in succf()/predf() (#140) And add more thorough test. Signed-off-by: Cary Phillips <cary@ilm.com> * Clean up setting of Imath version (#139) * Clean up setting of Imath version * Set the version via the project() statement in top-level CMakeLists.txt, so all version-related settings are close together in an obvious place. Deprecate config/version.cmake and move logic to top level * New option IMATH_VERSION_EXTRA to hold "dev" for the master branch * Simplfy logic for SOVERSION.SOAGE.SOREVISION (no more SOCURRENT) Signed-off-by: Cary Phillips <cary@ilm.com> * find_package uses CMAKE_PROJECT_VERSION instead of IMATH_VERSION And removed EXACT since IMATH_VERSION includes IMATH_VERISON_EXTRA. Signed-off-by: Cary Phillips <cary@ilm.com> * Bump SOVERSION to 28 Signed-off-by: Cary Phillips <cary@ilm.com> * Release notes for v3.0.2 Signed-off-by: Cary Phillips <cary@ilm.com> * Bump version for v3.0.2 Signed-off-by: Cary Phillips <cary@ilm.com> * Adjust SOVERSION/SOREVISION for v3.0.2 Signed-off-by: Cary Phillips <cary@ilm.com> * Change v3.0.2 release date to May 17 Signed-off-by: Cary Phillips <cary@ilm.com> * Fix order of ${IMATH_SOVERSION}.${IMATH_SOREVISION}.${IMATH_SOAGE} (#142) Revision comes before age. Signed-off-by: Cary Phillips <cary@ilm.com> * Changed release date of v3.0.2 to May 16 Signed-off-by: Cary Phillips <cary@ilm.com> Co-authored-by: Larry Gritz <lg@larrygritz.com>
cary-ilm
pushed a commit
to cary-ilm/openexr
that referenced
this pull request
May 17, 2021
) We were setting target_compile_features(${objlib} PUBLIC cxx_std_${OPENEXR_CXX_STANDARD}) The `PUBLIC` forced downstream projects that consume the `OpenEXRConfig*.cmake` exports to use C++ standard at least as recent as what OpenEXR used to build (which defaults to 14). But this is unnecessary. There's nothing in OpenEXR's headers that requires anything beyond C++11. So this patch uses a more fine-grained setting of target properties to express this more correctly. Now it will be fine for a C++11 project to consume OpenEXR (via its exported configs) even if that OpenEXR happened to be built with C++14. Signed-off-by: Larry Gritz <lg@larrygritz.com> Signed-off-by: Cary Phillips <cary@ilm.com>
cary-ilm
pushed a commit
that referenced
this pull request
May 17, 2021
We were setting
target_compile_features(${objlib} PUBLIC cxx_std_${OPENEXR_CXX_STANDARD})
The `PUBLIC` forced downstream projects that consume the
`OpenEXRConfig*.cmake` exports to use C++ standard at least as recent
as what OpenEXR used to build (which defaults to 14).
But this is unnecessary. There's nothing in OpenEXR's headers that
requires anything beyond C++11. So this patch uses a more fine-grained
setting of target properties to express this more correctly. Now it will
be fine for a C++11 project to consume OpenEXR (via its exported configs)
even if that OpenEXR happened to be built with C++14.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Signed-off-by: Cary Phillips <cary@ilm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We were setting
The
PUBLICforced downstream projects that consume theOpenEXRConfig*.cmakeexports to use C++ standard at least as recentas what OpenEXR used to build (which defaults to 14).
But this is unnecessary. There's nothing in OpenEXR's headers that
requires anything beyond C++11. So this patch uses a more fine-grained
setting of target properties to express this more correctly. Now it will
be fine for a C++11 project to consume OpenEXR (via its exported configs)
even if that OpenEXR happened to be built with C++14.
Signed-off-by: Larry Gritz lg@larrygritz.com