Rename external/OpenJPH/src/core/common to openjph, instead of using a symlink #2225
Conversation
This file contains hidden or 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
OpenJPH headers are included in application code with the openjph subdirectory: However, in the OpenJPH source tree, the headers live under a directory called "common", which means when OpenEXR builds the vendored copy of OpenJPH via `add_subdirectory`, the headers aren't in the expected "openjph" directory. The previous solution to this was to create a symlink from "openjph" to "common", but symlinks are fragile on Windows. If the git repo is cloned with `core.symlinks=false`, the symlink doesn't exist. This solution simply renames the "common" directory to "openjph" in the vendored OpenJPH code, adjusting references to it as necessary. The `vendor_openjph.sh` script does the proper renaming in the OpenJPH cmake configuration. This address the issue raised on AcademySoftwareFoundation#2193 after it was merged. Signed-off-by: Cary Phillips <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
OpenJPH headers are included in application code with the openjph subdirectory:
#include <openjph/ojph_version.h>However, in the OpenJPH source tree, the headers live under a directory called "common", which means when OpenEXR builds the vendored copy of OpenJPH via
add_subdirectory, the headers aren't in the expected "openjph" directory.The previous solution to this was to create a symlink from "common" to "openjph", but symlinks are fragile on Windows. If the git repo is cloned with
core.symlinks=false, the symlink doesn't exist.This solution simply renames the "common" directory to "openjph" in the vendored OpenJPH code, adjusting references to it as necessary. The
vendor_openjph.shscript does the proper renaming in the OpenJPH cmake configuration.An alternate solution would be to conditionally include
<common/ojph_version.h>when building against the vendored code, but that's message. At least this contains the weirdness inside the vendored code.For a longer term solution, I'll submit a request to change this upstream in OpenJPH.
This address the issue raised on #2193 after it was merged.