-
Notifications
You must be signed in to change notification settings - Fork 374
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
Modernize CMake #653
Merged
rettichschnidi
merged 5 commits into
eclipse-wakaama:master
from
husqvarnagroup:gardena/rs/modernize-cmake
Feb 4, 2022
Merged
Modernize CMake #653
rettichschnidi
merged 5 commits into
eclipse-wakaama:master
from
husqvarnagroup:gardena/rs/modernize-cmake
Feb 4, 2022
Conversation
This file contains 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
There is no need for declaring another ret variable.
sanititzed -> sanitized
This should work equally well and does not waste resources on multiple checkouts.
Before this, the build system set many flags and defines globally, making it hard-to-impossible to build binaries with freely chosen combinations of defines in the same build tree. With this new design, compilation flags are bound to their targets, which is the preferred style since CMake ~3.0. Pro: - Unit tests and compilation checks can cover arbitrary (all!) defines - Simplified usage when including Wakaama in a CMake based project: - include wakaama.cmake - add_executable(your-binary ...) - target_compile_definitions(your-binary ...) - target_sources_wakaama(your-binary) - DTLS enabled example client built next to the plaintext one. This will make it easier to integrate both binaries in the same integration test run. Con: - Building the example client project requires the tinydtls submodule to be checked out. Same goes for the top level "wakaama" project, which includes the example client.
cmake-format ensures that our CMake code adheres to the format accepted by cmake-format. The code style is based on default one, with some minor adjustments.
rettichschnidi
force-pushed
the
gardena/rs/modernize-cmake
branch
from
January 31, 2022 13:14
100d941
to
f6a761c
Compare
mlasch
approved these changes
Feb 4, 2022
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good with cmake-format
in place.
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.
Before this, the build system set many flags and defines globally,
making it hard-to-impossible to build binaries with freely chosen
combinations of defines in the same build tree.
With this new design, compilation flags are bound to their targets,
which is the preferred style since CMake ~3.0.
Pro:
will make it easier to integrate both binaries in the same
integration test run.
Con:
to be checked out. Same goes for the top level "wakaama" project,
which includes the example client.
As most CMake files had to be changed to implement, I also integrated CMake code formatting enforcement as discussed in #574.