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.
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 https://github.com/ThrowTheSwitch/Ceedling/issues/706
This PR is dependent on this PR: https://github.com/ThrowTheSwitch/Ceedling/pull/728