cmake: drop CURL_DISABLE_TESTS option#16134
Closed
vszakats wants to merge 3 commits into
Closed
Conversation
CURL_DISABLE_TESTS optionCURL_DISABLE_TESTS option (? or drop?)
CURL_DISABLE_TESTS option (? or drop?)CURL_DISABLE_TESTS option (or drop?)
CURL_DISABLE_TESTS option (or drop?)CURL_DISABLE_TESTS option (or drop/deprecate?)
CURL_DISABLE_TESTS option (or drop/deprecate?)CURL_DISABLE_TESTS option
Member
Author
CURL_DISABLE_TESTS optionCURL_DISABLE_TESTS option (or delete/document?)
CURL_DISABLE_TESTS option (or delete/document?)CURL_DISABLE_TESTS option
CURL_DISABLE_TESTS optionCURL_DISABLE_TESTS option
CURL_DISABLE_TESTS optionCURL_DISABLE_TESTS option
c238f86 to
4d89629
Compare
CURL_DISABLE_TESTS optionCURL_DISABLE_TESTS option
CURL_DISABLE_TESTS optionCURL_DISABLE_TESTS option
pps83
pushed a commit
to pps83/curl
that referenced
this pull request
Apr 26, 2025
curl builds tests with CMake when explicitly building the `testdeps` target. It's not built by default. It seems overkill to have a curl-specific variant of this (over CMake's `BUILD_TESTING`) to disable generating this target. Its history also doesn't make it obvious why this was necessary, and there was a long debate how to do it, by the time the original submitter abandoned CMake. The option also remained uninitialized and thus undocumented. Let me know if I missed something. Ref: curl#6036 Ref: 3a1e798 curl#6072 Closes curl#16134
vszakats
added a commit
to vszakats/curl
that referenced
this pull request
Dec 11, 2025
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
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.
curl builds tests with CMake when explicitly building the
testdepstarget. It's not built by default. It seems overkill to have
a curl-specific variant of this (over CMake's
BUILD_TESTING)to disable generating this target.
Its history also doesn't make it obvious why this was necessary,
and there was a long debate how to do it, by the time the original
submitter abandoned CMake. The option also remained uninitialized
and thus undocumented.
Let me know if I missed something.
Ref: #6036
Ref: 3a1e798 #6072
I wonder if this option is useful. According to the linked Issues, its goal is to disable building tests for curl specifically, when in nested projects
BUILD_TESTINGwould disable this for all other projects as well.But, tests are not built in curl by default regardless of these settings. These control if the
testdepstarget is present or excluded at the "generation" step. Excluding this target saves near zero time there.Test targets are build only when explicitly building the
testdepstarget. Maybe this target is also used in other projects? GitHub search reports this string being present in just a tiny number of projects: https://github.com/search?q=testdeps+language%3Acmake&type=codeIf it would be a widely used name, perhaps renaming to
curl-testswould be a better way to go. (and match how we fixed this for other target names.)Or perhaps there is another shared mechanism to kick off (actually) building tests?
Any thoughts?