Skip to content

fix bug in CMake preventing user from disabling testing #506

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 21, 2025

Conversation

aaronj0
Copy link
Collaborator

@aaronj0 aaronj0 commented Feb 21, 2025

There is a bug in the CMake where
option(CPPINTEROP_ENABLE_TESTING "Enables the testing infrastructure." BOOL)
is conditional and for non-Emscripten builds the default is explicitly set to ON. This is incorrect and does not allow users to override the option, leading to testing always being on.

The option keyword must be defined once with one default, which CMake then overrides from the user's command line option

@aaronj0 aaronj0 requested a review from vgvassilev February 21, 2025 09:58
CMakeLists.txt Outdated
endif()

option(CPPINTEROP_ENABLE_TESTING "Enable the CppInterOp testing infrastructure." ${default_testing})

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

This looks good. Just curious if we can improve it this way and remove the use of the extra var introduced ...

  1. So below these we introduce the default option we want
    option(CPPINTEROP_USE_CLING "Use Cling as backend" OFF)
    option(CPPINTEROP_USE_REPL "Use clang-repl as backend" ON)
option(CPPINTEROP_ENABLE_TESTING "Enable the CppInterOp testing infrastructure." ON)
  1. And for the emscripten case, we just set the same var as off (of course till in the future we enable testing for this platform too and can remove this)
set(CPPINTEROP_ENABLE_TESTING OFF)

So its just one line at the top that the user controls.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Indeed that makes much more sense instead of setting a default variable

@mcbarton
Copy link
Collaborator

@aaronj0 @vgvassilev As part of my automated wasm tests PR here #483 the tests are on by default for both situations, so don't believe this PR is needed.

Copy link
Collaborator

@mcbarton mcbarton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't believe this change is needed due to automated wasm tests PR. Will wait for comment.

@aaronj0
Copy link
Collaborator Author

aaronj0 commented Feb 21, 2025

This is a patch needed for ROOT today

@aaronj0 @vgvassilev As part of my automated wasm tests PR here #483 the tests are on by default for both situations, so don't believe this PR is needed.

I don't understand what you mean. This is a pretty serious bug, ROOT does not even build with testing off since the current code forces the unittests subdir and then breaks with gtest not found. You can always rebase that PR, but I'm not going to drop this important fix for the sake of that

@mcbarton
Copy link
Collaborator

Just realised this PR is about allowing the user to override having the tests enable. Sorry, misread the PR description.

@aaronj0
Copy link
Collaborator Author

aaronj0 commented Feb 21, 2025

Just realised this PR is about allowing the user to override having the tests enable. Sorry, misread the PR description.

Can you please drop your changes requested, although I see no changes being requested.

@mcbarton
Copy link
Collaborator

Just realised this PR is about allowing the user to override having the tests enable. Sorry, misread the PR description.

Can you please drop your changes requested, although I see no changes being requested.

Already have as far as I can tell.

@mcbarton mcbarton merged commit b0c3e36 into compiler-research:main Feb 21, 2025
48 checks passed
@aaronj0
Copy link
Collaborator Author

aaronj0 commented Feb 21, 2025

@mcbarton Please refrain from merging PR's like that. I was waiting for the CI run to pass, and a review from @vgvassilev

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants