Skip to content
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

Building without tests-tools #14268

Merged
merged 2 commits into from
Feb 2, 2025
Merged

Building without tests-tools #14268

merged 2 commits into from
Feb 2, 2025

Conversation

PPN-SD
Copy link
Contributor

@PPN-SD PPN-SD commented Jan 31, 2025

Today, we can't build mixxx without links to gtest/gperftools/benchmark

This PR allows building only mixxx and mixxx-lib targets without tests-tools.

Two common cmake-definitions are added :

  • BUILD_TESTING
  • BUILD_BENCH

And one compile definition for test.main.cpp :

  • USE_BENCH

This is helpful for packaging (gentoo here).

The negative effect is sorting of tests source files as soon as they are called by mixxx-benchmark target.

Duplicate of a previous messy PR : #14264

@PPN-SD
Copy link
Contributor Author

PPN-SD commented Jan 31, 2025

@daschuer I think it's ready. Bench and testing by default if no def.
benchmark is now required for gperftools options.

@daschuer
Copy link
Member

Thanks. Before merge, we need you approval:
https://docs.google.com/a/mixxx.org/spreadsheet/viewform?formkey=dEpYN2NkVEFnWWQzbkFfM0ZYYUZ5X2c6MQ
Can you please sign this form and comment here when done?

@PPN-SD
Copy link
Contributor Author

PPN-SD commented Jan 31, 2025

Can you please sign this form and comment here when done?

Done. Fixed code style.

CMakeLists.txt Outdated
Comment on lines 2388 to 2396
if(NOT DEFINED BUILD_TESTING)
find_package(GTest CONFIG)
if(GTest_FOUND)
message(STATUS "Found GTest: tests enabled")
set(BUILD_TESTING ON)
endif()
elseif(BUILD_TESTING)
find_package(GTest CONFIG REQUIRED)
if(GTest_FOUND)
message(STATUS "Found GTest")
endif()
endif()
Copy link
Member

Choose a reason for hiding this comment

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

What is the reason for not doing:

Suggested change
if(NOT DEFINED BUILD_TESTING)
find_package(GTest CONFIG)
if(GTest_FOUND)
message(STATUS "Found GTest: tests enabled")
set(BUILD_TESTING ON)
endif()
elseif(BUILD_TESTING)
find_package(GTest CONFIG REQUIRED)
if(GTest_FOUND)
message(STATUS "Found GTest")
endif()
endif()
find_package(GTest CONFIG)
cmake_dependent_option(
BUILD_TESTING
"Build with Unittests"
OFF
"GTest_FOUND"
ON
)
if(BUILD_TESTING AND NOT GTest_FOUND)
message(FATAL_ERROR "GTest is required for DBUILD_TESTING=ON")
endif()

same below

Copy link
Contributor Author

@PPN-SD PPN-SD Jan 31, 2025

Choose a reason for hiding this comment

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

None. But you mean OFF/ON-> ON/OFF no ?

Copy link
Member

Choose a reason for hiding this comment

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

Oh yes sure. Sorry.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, just noticed that cmake_dependent_option() does not work, because it forces the value to "OFF" independent form the user value. We want:
default_option(BUILD_TESTING, "Build with Unittests", "GTest_FOUND")

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The commit's logic is clear and CMakeMagic doesn't decrease the number of lines.

Copy link
Member

Choose a reason for hiding this comment

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

default_option(BUILD_TESTING, "Build with Unittests", "GTest_FOUND")

Reuses a bit of the complexity used elsewhere in our CMakLists.txt.
That's why I prefere this. But I don't insist.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK. I'll check that.
PR 2.5 pushed.

@daschuer
Copy link
Member

Grenade on 2.5 now?

@PPN-SD
Copy link
Contributor Author

PPN-SD commented Jan 31, 2025

Grenade on 2.5 now?

#14269

@PPN-SD PPN-SD force-pushed the cmake-mixxx-main branch 2 times, most recently from 695ae64 to 14626ee Compare February 1, 2025 00:39
Today, we can't build mixxx without links to gtest/gperftools/benchmark

This PR allows building only mixxx and mixxx-lib targets without
tests-tools.

Two common cmake-definitions are added :
* BUILD_TESTING
* BUILD_BENCH

And one compile definition for test.main.cpp :
* USE_BENCH

This is helpful for packaging (gentoo here).

The negative effect is sorting of tests source files as soon
as they are called by mixxx-benchmark target.

Signed-off-by: Nicolas PARLANT <[email protected]>
@PPN-SD
Copy link
Contributor Author

PPN-SD commented Feb 2, 2025

Does that sound better?

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

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

LGTM, thank you.

@daschuer daschuer merged commit ee51cec into mixxxdj:main Feb 2, 2025
13 checks passed
@PPN-SD PPN-SD deleted the cmake-mixxx-main branch February 2, 2025 12:52
@jospezial
Copy link

@daschuer I wonder, doesn't the double merge into main

  1. from this PR
  2. from the 2.5 branch via 45cfe5d merge
    cause any problems to the git and history?
    Or does it happen often and github solves this itself?
    Was this PR for main unnecessary? I have not checked for code differences between the 2 PRs.

@daschuer
Copy link
Member

daschuer commented Feb 3, 2025

Yes, the main PR was unnecessary.
We keep 2.5 merge-able into main. Bugfixes go to 2.5 and new features to main. We now and then merge 2.5 to main to have the bugs fixed there as well.

In our case the 2.5 to main merge was conflicting. I have resolved the conflicts, so everything is fine again.

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

Successfully merging this pull request may close these issues.

3 participants