Ensure that orocos_kdl_vendor doesn't accidentally find itself. #27
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
When initially building the orocos_kdl_vendor package (on platforms where it actually builds), it turns out that it places a valid cmake configuration in the build directory. In turn, that means that a subsequent rebuild will find this configuration in the build directory, and throw the rest of the logic off. This only seems to be a problem with CMake 3.29 and later, though I can't say exactly why at the moment. Workaround this problem by writing the configuration out to a temporary file, and then moving it into the final place with the final name. Signed-off-by: Chris Lalancette <clalancette@gmail.com>
|
CI:
|
ahcorde
approved these changes
May 6, 2024
|
The warnings in CI are unrelated to this change, as none of the failed tests use orocos_kdl_vendor at all. Thus, going ahead and merging this one in. |
|
@Mergifyio backport jazzy |
✅ Backports have been created
|
mergify bot
pushed a commit
that referenced
this pull request
May 7, 2024
When initially building the orocos_kdl_vendor package (on platforms where it actually builds), it turns out that it places a valid cmake configuration in the build directory. In turn, that means that a subsequent rebuild will find this configuration in the build directory, and throw the rest of the logic off. This only seems to be a problem with CMake 3.29 and later, though I can't say exactly why at the moment. Workaround this problem by writing the configuration out to a temporary file, and then moving it into the final place with the final name. Signed-off-by: Chris Lalancette <clalancette@gmail.com> (cherry picked from commit 7aad6d1)
ahcorde
pushed a commit
that referenced
this pull request
May 8, 2024
…#28) When initially building the orocos_kdl_vendor package (on platforms where it actually builds), it turns out that it places a valid cmake configuration in the build directory. In turn, that means that a subsequent rebuild will find this configuration in the build directory, and throw the rest of the logic off. This only seems to be a problem with CMake 3.29 and later, though I can't say exactly why at the moment. Workaround this problem by writing the configuration out to a temporary file, and then moving it into the final place with the final name. Signed-off-by: Chris Lalancette <clalancette@gmail.com> (cherry picked from commit 7aad6d1) Co-authored-by: Chris Lalancette <clalancette@gmail.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.
When initially building the orocos_kdl_vendor package (on platforms where it actually builds), it turns out that it places a valid cmake configuration in the build directory. In turn, that means that a subsequent rebuild will find this configuration in the build directory, and throw the rest of the logic off. This only seems to be a problem with CMake 3.29 and later, though I can't say exactly why at the moment.
Workaround this problem by writing the configuration out to a temporary file, and then moving it into the final place with the final name.
This is the final fix needed to allow us to upgrade Windows to OpenSSL 3.3.0; see ros-infrastructure/ros2-cookbooks#68 for details.