Allow the combination of use_test_preprocessor and CMock's treat_inlines #421
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.
I expect this combination to be pretty common especially in embedded unit testing. Often the preprocessor is needed because the vendor headers alone are too complex and tricky to be parsed correctly without preprocessing (NXP, STM, ...). Not to mention the own developed header files.
On the other hand you want to mock the evil inline functions that try to directly manipulate non existing registers. Even if you fake-map the registers into the host runner RAM you still have no control if the inline function was called or not. You gain a more fine grained control over your tests if the inline functions are mocked.
Unfortunately the combination of preprocessor and treat_inlines creates a copy of the original header in the include path which is stripped of all macros (=preprocessed). When the following GCC build of unit test itself is in anyway dependent on these macros the build will fail. This MR allows the specific mechanism of removing the static/inline keywords for the header copy to operate on the original file instead of the preprocessed file. While other operations of CMock run on the preprocessed file so there is no change in behaviour there.
I am not particular happy about this pull request concerning the code quality itself. It was my first touch with ruby/rake ever and I am just glad I achieved the level "works for us". Probably the tests need to be fixed. Probably there is a better or complete different way to resolve this. I just wanted to provide this to give an idea how it works. But I am also ready and willing to improve it, if you have some suggestions.
For more information compare the issue ThrowTheSwitch/Ceedling#706
This PR is dependent on this PR: ThrowTheSwitch/Ceedling#728