fix: don't use DEPENDS with add_custom_command(TARGET) #5074
+0
−1
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.
Release Summary:
Resolved issues:
resolves #5073
Description of changes:
We can use
DEPENDS
foradd_custom_command(OUTPUT)
but can't useDEPENDS
foradd_custom_command(TARGET)
.See also the
add_custom_command(TARGET)
document:https://cmake.org/cmake/help/latest/command/add_custom_command.html#build-events
If we use
DEPENDS
foradd_custom_command(TARGET)
, the following warning is reported:We can just remove
DEPENDS
to suppress the warning.Call-outs:
Address any potentially confusing code. Is there code added that needs to be cleaned up later? Is there code that is missing because it’s still in development? If a callout is specific to a section of code, it might make more sense to leave a comment on your own PR file diff.
Testing:
How is this change tested (unit tests, fuzz tests, etc.)? What manual testing was performed? Are there any testing steps to be verified by the reviewer?
cmake -DS2N_INTERN_LIBCRYPTO=ON
doesn't report the warning with this.How can you convince your reviewers that this PR is safe and effective?
This just removes the warned and ignored argument.
Is this a refactor change? If so, how have you proved that the intended behavior hasn't changed?
No.
Remember:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.