-
Notifications
You must be signed in to change notification settings - Fork 277
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
CMake: Add Features for docs, unit tests #400
Conversation
CMake 3.16:
|
Codecov Report
@@ Coverage Diff @@
## develop #400 +/- ##
===========================================
+ Coverage 42.37% 43.22% +0.84%
===========================================
Files 129 130 +1
Lines 13276 12932 -344
===========================================
- Hits 5626 5590 -36
+ Misses 7650 7342 -308
Continue to review full report at Codecov.
|
- A new CMake option, ENABLE_TESTS, is created and defaults ON (Legacy -DDISABLE_TESTS=1 on the command line will override) - Target info for docs and tests is shown in the FeatureSummary
The same old variables will be respected for setting the path, but the PREFERRED method is defining `-DUnitTest++_ROOT=/path/to` on the CMake command line. _ROOT variables are handled with extra intelligence by CMake. The find module will also attempt to locate the pkg-config file UnitTest++.pc, and if found will import its data.
f8fcb8c
to
7ab18fd
Compare
Oh, I forgot to mention: if pkg-config is used to configure UnitTest++, it'll also pick up and report the version during CMake's generation process:
|
@ferdnyc Any risk of this breaking on build servers? Should we test on a dedicated branch, or has that already been done? I'm okay merging if you feel it's safe though. |
@jonoomph No significant danger. I tested the configs locally with CMake 3.2, as well as Fedora's current 3.16. |
I SHOULD check whether there are any changes to Edit: (Well, that didn't happen, but only because I fell asleep at 7pm and just slept for 12 hours. I'll get to it; there's no urgency as this is purely build-housekeeping. #SoTired) |
I'm actually going to merge this, because I just experimentally discovered that on Windows, trying to build without this change will fail if UnitTest++ is not installed. With these changes, it's correctly skipped. (The unit tests are simply disabled, as intended.) Any changes to the Gitlab builder configs should be optional, not required, so those can happen separately. |
(I will of course check on the Gitlab builders now...) |
Everything configured fine. Amusingly, the presence of a version number in the discovery logs indicates that the macOS builder used
but the Linux builder DIDN'T:
...I don't even know what to make of that. (Maybe it's because Linux has (only?) the static-lib version of UnitTest++, not the shared lib. Or it could be that the name is different — on my Fedora system, the shared lib is named Regardless, doesn't affect anything with the build. |
-DENABLE_TESTS=0
to disable. (Legacy-DDISABLE_TESTS=1
will also override)RECOMMENDED
, notREQUIRED
, since libopenshot can be built without running unit testsI also briefly broke
FindUnitTest++.cmake
, at one point completely changed the name toFindUnitTestCpp.cmake
, and then ended up restoring the original name.(There's a bug in CMake that prevents certain features of
FindPackageHandleStandardArgs()
from being used with module names that contain regular expression special characters (like+
) — I actually submitted a change to CMake that fixes that issue, which was merged so in the future it won't be a concern. But since we support older releases, simplest solution is to just avoid making use of the feature (FOUND_VARIABLE
) in question, which is what the new code does.)By way of penance, when I restored the original module name I also added
pkg-config
support, so if UnitTest++ is installed in a standard system location (or if itspkgconfig
directory location is added to the list of paths in thePKG_CONFIG_PATH
environment variable) thenFindUnitTest++.cmake
will pick up aUnitTest++.pc
file and import that info into the build environment.No
IMPORTED
targets yet, though that's still on my goals list for this PR before merging. If it seems like it's just not gonna happen, I'll merge without and do that some time in the future.The same old (environment,cache) variables will still work to set its path, but the PREFERRED way of specifying the location of UnitTest++ is by adding a
-DUnitTest++_ROOT=/path/to/unittest++
argument to the CMake command line.pkgname_ROOT
variables are handled with extra intelligence by CMake 3.12+, and the Find module (most, if not all, of our find modules now) now has forward-compatibility code that explicitly looks for those variables, so they'll work on older versions as well.