refactor(quality control): Use an isolated version of CFA_Config.hpp
for Defect Detector environment.
#117
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.
Overview
This is a quick follow-up to 5b5a898.
Instead of the Defect Detector using
CFA_Config.hpp
, the defines in the configuration are declared in thebuild_flags
section of the Defect Detector's environment.Benefits
Any configurations made to
CFA_Config.hpp
no longer affects the outcome of my overall Quality Control.This frees
CFA_Config.hpp
to be set to whichever way I want/need it to be to provide the best quality default configuration that most people will use.It also means that I can run various combinations of configurations through my Defect Detector without affecting
CFA_Config.hpp
. Say, if I wanted to disableCRSF_RC_ENABLED
but I wanted to leaveCRSF_TELEMETRY_ENABLED
turned on, I can do that without touchingCFA_Config.hpp
.In other words...
This is mostly a quality-of-life thing from a developer's point-of-view.
The more modular CRSF for Arduino is, the easier it is to test key aspects in isolation, and (by extension) that means improving the overall quality of the code-base.