UnitTest++ now correctly supports CMake's find_package config mode #173
Conversation
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
|
What is the minimum version that supports find_package? That's the version
it should support.
…On Wed, 14 Aug 2019, 17:43 Dan Huantes, ***@***.***> wrote:
[CMakeLists.txt]
- Bumped cmake minimum requirement to go to 3.14 as I'm
not able to test with an older version
- Added version to project so that is evident
when looking at CMakeLists.txt
- Removed include_directories as that command
affects more than just UnitTest++ in favor
of target_include_directories.
- The target_include_directories uses the
generator expressions to do the same thing
for the BUILD_INTERFACE condition but only
affects UnitTest++. The INSTALL_INTERFACE
ensures that when UnitTest++ is installed
client applications calling find_package
for UnitTest++ only have to add the
UnitTest++ target to the target_link_libraries
and will get the correct include path
for UnitTest++ added to their include paths.
- Added DEBUG_POSTFIX to both library and
unit test to distinguish them from each other
as they are installed into the same directory
and would otherwise overwrite one another.
- Added Versioning using write_basic_package_version_file
to the install so that a client can call
find_package(UnitTest++ 2.1 REQUIRED) and it will be
able to confirm the version. If the version is updated
you could theoretically ahve a version 2.2, 2.3 ,etc...
and the find_package mechanism will find the correct one.
the SameMajorVersion option in that call indicates
that 2.3 is compatible with 2.1 or in other words if
find_package(UnitTest++ 2.1 REQUIRED) is called and
2.3 is installed that satisfies the condition but
if only 3.0 was installed it will fail because of
'SameMajorVersion'.
- Also added installation for the Version file.
------------------------------
You can view, comment on, or merge this pull request online at:
#173
Commit Summary
- UnitTest++ now correctly supports CMake's find_package config mode
File Changes
- *M* CMakeLists.txt
<https://github.com/unittest-cpp/unittest-cpp/pull/173/files#diff-0
8000
>
(25)
Patch Links:
- https://github.com/unittest-cpp/unittest-cpp/pull/173.patch
- https://github.com/unittest-cpp/unittest-cpp/pull/173.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#173?email_source=notifications&email_token=ABGL3HEWD4QDXRHB44X73DTQEQY2LA5CNFSM4ILW3BZ2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HFIEE6A>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGL3HAZMZQWBT4XWGU4OR3QEQY2LANCNFSM4ILW3BZQ>
.
|
|
find_package has been around a long time but the Transitive Usage requirements (I think) were introduced in 3.0/3.1 time frame.. But just noticed that the travis-ci failed and it failed because it has 3.12.4 installed and not the 3.14 requested. Do you think I should drop back to requiring only 3.1 or 3.12 so that the CI tests pass? |
|
I am always wary of bumping versions. I recently worked on a project that
used Ubuntu 14_04 and all that entails (gcc 4.8, etc). I am pretty sure
that version was 2.9. It's been a while so I may be misremembering.
Never go higher than you need to.
If the CI fails due to version that reduce it. But make sure it is the
bare minimum to support the features, but not the bare maximum to pass.
Just did a quick Google and found a page that documents using it in CMake
2.6 so do you really need to bump the version?
GR
…On Wed, 14 Aug 2019, 18:02 Dan Huantes, ***@***.***> wrote:
find_package has been around a long time but the Transitive Usage
requirements (I think) were introduced in 3.0/3.1 time frame.. But just
noticed that the travis-ci failed and it failed because it has 3.12.4
installed and not the 3.14 requested. Do you think I should drop back to
requiring only 3.1 or 3.12 so that the CI tests pass?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#173?email_source=notifications&email_token=ABGL3HC7AXZHPVVMFDU6AE3QEQ3CJA5CNFSM4ILW3BZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4JOHWY#issuecomment-521331675>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGL3HCNTBCCTC46HF7PWVLQEQ3CJANCNFSM4ILW3BZQ>
.
|
|
The change leverages transitive usage requirements. From everything I've researched the minimum version required is 3.0. So will bump it back down and hope the travis-ci clang Release test passes. Since I didn't change any code not sure why it would suddenly start failing only that test. We'll see. Thanks. |
[CMakeLists.txt] - Bumped cmake minimum requirement to go to 3.0 as this appears to be earliest version that transitive usage requirements are supported. - Added version to project so that is evident when looking at CMakeLists.txt - Removed include_directories as that command affects more than just UnitTest++ in favor of target_include_directories. - The target_include_directories uses the generator expressions to do the same thing for the BUILD_INTERFACE condition but only affects UnitTest++. The INSTALL_INTERFACE ensures that when UnitTest++ is installed client applications calling find_package for UnitTest++ only have to add the UnitTest++ target to the target_link_libraries and will get the correct include path for UnitTest++ added to their include paths. - Added DEBUG_POSTFIX to both library and unit test to distinguish them from each other as they are installed into the same directory and would otherwise overwrite one another. - Added Versioning using write_basic_package_version_file to the install so that a client can call find_package(UnitTest++ 2.1 REQUIRED) and it will be able to confirm the version. If the version is updated you could theoretically ahve a version 2.2, 2.3 ,etc... and the find_package mechanism will find the correct one. the SameMajorVersion option in that call indicates that 2.3 is compatible with 2.1 or in other words if find_package(UnitTest++ 2.1 REQUIRED) is called and 2.3 is installed that satisfies the condition but if only 3.0 was installed it will fail because of 'SameMajorVersion'. - Also added installation for the Version file.
88a9fc0 to
2423fca
Compare
Found that Crashing tests at some point in Clang history were actually caught but testing on Clang 6.0 and Clang 7.0 this is not the case. So added Clang to the list of compilers that don't run this tests. Noted that several other Pull Requests were failing for the same reason.
|
All test pass now... Acceptable for merging? |
|
@dhuantes Probably, will review at my earliest opportunity. |
|
@pjohnmeyer Have you had a chance to look at this yet? Just curious. Thank you. |
pjohnmeyer
requested changes
Oct 16, 2019
CMakeLists.txt
Outdated
| cmake_minimum_required(VERSION 2.8.1) | ||
| project(UnitTest++) | ||
| cmake_minimum_required(VERSION 3.0) | ||
| project(UnitTest++ VERSION 2.1) |
There was a problem hiding this comment.
Let's make the version explicitly 3 parts. I agree that changing the CMake requirement merits a minor version bump, though, not a patch bump, so 2.1.0:
Suggested change
| project(UnitTest++ VERSION 2.1) | |
| project(UnitTest++ VERSION 2.1.0) |
I'm not aware of CMake supporting -pre or -beta suffixes to distinguish this from a release version but I haven't been active with CMake in years.
There was a problem hiding this comment.
Thanks. Just made and pushed the changes requested.
- Updated to appveyor.yml and configure.ac to 2.1.0 to match CMake project version.
pjohnmeyer
approved these changes
Oct 17, 2019
|
@pjohnmeyer Just coming back to a project that uses unittest-cpp and noted this pull request had not yet been merged. Seems like it's ready to go. Any chance of making that happen? Thanks. |
[CMakeLists.txt] - It is standard practice to have a namespace for an imported target. Added UnitTest++:: as the namespace argument so that find_package(UnitTest++) will result in UnitTest++::UnitTest++ target that will be used in target_link_libraries. - Updated target_link_libraries for TestUnitTest++ as an example
|
@dhuantes yup, merging now. Sorry for the delay -- I was laid off recently for COVID-related reasons and I am in the middle of an unplanned job search. |
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.
[CMakeLists.txt]
not able to test with an older version
when looking at CMakeLists.txt
affects more than just UnitTest++ in favor
of target_include_directories.
generator expressions to do the same thing
for the BUILD_INTERFACE condition but only
affects UnitTest++. The INSTALL_INTERFACE
ensures that when UnitTest++ is installed
client applications calling find_package
for UnitTest++ only have to add the
UnitTest++ target to the target_link_libraries
and will get the correct include path
for UnitTest++ added to their include paths.
unit test to distinguish them from each other
as they are installed into the same directory
and would otherwise overwrite one another.
to the install so that a client can call
find_package(UnitTest++ 2.1 REQUIRED) and it will be
able to confirm the version. If the version is updated
you could theoretically ahve a version 2.2, 2.3 ,etc...
and the find_package mechanism will find the correct one.
the SameMajorVersion option in that call indicates
that 2.3 is compatible with 2.1 or in other words if
find_package(UnitTest++ 2.1 REQUIRED) is called and
2.3 is installed that satisfies the condition but
if only 3.0 was installed it will fail because of
'SameMajorVersion'.