Closed pileghoff closed 2 months ago
pileghoff
commented
2 months ago Our big issue is actually the following case, just in case it helps with a more realistic use-case:
#ifdef FEATURE_A
#include "feature_a_dependency.h"
TEST_SOURCE_FILE("feature_a.c")
void test_a(void)
{
TEST_ASSERT_EQUAL_INT(1, feature_a());
}
#endifThis fails to link if FEATURE_A is not set, since feature_a.c is built, but it relies on functions in feature_a_dependency.[ch], which is not built.
mkarlesky
commented
2 months ago Hi, @pileghoff. This is an interesting edge case. We'll need to add some documentation to address it. There's a variety of preprocessing steps Ceedling performs — optional and mandatory. TEST_SOURCE_FILE() is only a “marker”, if you will (provided by Unity, actually). It's a do-nothing macro that Ceedling can scan for but ultimately is processed away to nothing. In order for that marker to do its job, it must be scanned for first before any other preprocessing steps. This is a simple string-based scan. The actual compiler toolchain C preprocessor will later completely wipe it away.
Previous versions of Ceedling had a (unreliable) means of preserving a certain class of macros like TEST_SOURCE_FILE() (at the time it mainly targeted Unity's test range macros). We had to pull that out in the big revamp for 1.0.0. It's on the list to figure out how to restore that functionality in a more resilient way. When we do restore it—assuming we find a good way to do it—it will handle the case you've reported here.
Would it work to split your test files by feature? With Ceedling 1.0.0's features for building each test file as a mini project, you could provide each test executable build the #define symbols it needs (i.e. FEATURE_A for only some test executables) with the TEST_SOURCE_FILE() statement in the open inside those with no conditional compilation guards around it. If you had a lot of overlap of test cases and wanted to avoid duplication, I believe you could #include a .c file in the feature-specific test files containing the test cases in common and enable Ceedling’s preprocessing for your test files. You'd need to name the file that contains test cases in common something other than the convention Ceedling recognizes for test files meant to become test executables.
pileghoff
commented
2 months ago Its not really feasible for us to split out the different features into different tests, but we dont use TEST_SOURCE_FILE that often, so i would much rather find a workaround for those few cases.
The only time where we need it, is for 3rd party code where the header and source filenames dont match, and in those cases we could just make some test specific header files with matching names (or include the c files as you mention.)
Just wanted to report this as it seemed like a regression in the rc (for which we are very exited btw! good job!).
mkarlesky
commented
2 months ago Thank you so much for the report. Come to think of it (checks docs) we did document this unsupported feature interaction in the Changelog — that is admittedly now a lot to digest.
Ceedling is not yet capable of preserving build directive macros through preprocessing of test files. If, for example, you wrap these macros within conditional compilation preprocessing statements, they will not work as you expect.
I just clarified that statement a bit and improved the relevant discussion in BreakingChanges that did not adequately address this. CeedlingPacket does not address this at all but should. I've made a note to update that doc too.
Of course, the best solution is to simply cause Ceedling to do the right thing in these scenarios. We hope to get there soon!
A minimal example of the issue:
This will fails with the error:
Due to the fact that
TEST_SOURCE_FILE("does_not_compile.c")is not included after preprocessing, i dont expect ceedling to actually build the file. This seemed to work on 0.31, but is broken in 1.0.0-533d636We use this in our setup with different build flags (and obviously not just
#if 0).