ThrowTheSwitch
test_includes_preprocessor has a different call API than the other tools
Compiler tools have all two arguments, ${1} = source, ${2} = output, BUT :test_includes_preprocessor which has only ${1} = source, and expects the output on stdout.
This is inconvenient for the users, since if they use compiler options that produce debugging or verbose information on stdout, this breaks the preprocessing with bad results. (eg. clang -H or clang -v).
I would suggest to use an uniform call sequence for all the compiler tools, with both ${1} and ${2} and to let stdout and stderr free, including for :test_includes_preprocessor.
Also, in the meantime, if a user reports that his mock files are not generated despite :use_test_preprocessor: TRUE, let's suggest her to check the options of her :test_includes_preprocessor configuration.
Hi, @informatimago. Thanks for all your input on a variety of issues.
I believe this problem is no longer a problem in pre-release 0.32, but I think need to understand your report better first before saying that.
:flags and :defines handling has more flexibility and is more robust in 0.32. If you enable :use_test_preprocessor, Ceedling will default to providing cpp the same flags and symbols as the test compiler. However, by setting flags and defines for the preprocessor build step, these are used instead. So, I believe you should now be able to set verbose output for compilation but avoid it for preprocessing operations.
The reason the preprocessing tool definitions do not include a file output option (only $stdout) is by design. The output of these tools is only used internally by Ceedling directly from $stdout. Any subsequent file generation is by Ceedling itself after processing that output.
Could you tell me a bit more about your use case and the problem?
Would you mind reading the greatly revised sections on :flags and :defines in the 0.32 version of CeedlingPacket and let me know if I'm understanding you correctly and if these changes handle the problem for you?
The problem I was trying to solve was with headers.
I had to compile and test system level code, which defined its own version of standard headers such as string.h stdio.h etc. (I wasn't allowed to rename them). Furthermore, the tests had to run in a linux environment (on qemu), so the test code itself could need to include these standard headers, but from a provided sysroot.
It is a mess, but this is what I had to deal with. So it was very important to control the include search path, and the order in which the header themselves where included. (This is also the reason for another issue, since ceedling builds lists of included files, but before my patches the order depended on external factors such as the file system).
To be able to see what was going on when a collision occurs, I used the -H option, which would make the compiler driver dump on stdout the list of included file absolute paths.
Since test_includes_preprocessor uses the stdout for its own purposes, and there's no option to specify where the output of -H must go, I couldn't use -H for test_includes_preprocessor.
Thank you so much for explaining more.
For a troubleshooting need like this, is there a particular reason to run the test suite with : use_test_preprocessor enabled? Would running a simple build and working through errors one at a time be an option?
The test preprocessor tool in Ceedling is exposed to a certain degree, but it's largely meant for internal use only. There might be a way to reconfigure things a bit to make space for your use case in the future. I will look into it. The details of how Ceedling does test preprocessing are highly intertwined to the particular features and functions of cpp — especially ingesting $stdout without extra output from additional parameters. Incidentally, while Ceedling 0.32 has greatly improved test preprocessing and fixed numerous bugs in preprocessing, it continues to rely on a direct $stdout dump.
As for your search path needs, Ceedling 0.32 now allows you to customize your header search path for each test executable. It does this through combining the use of an existing basic feature (:paths ↳ :include) and a new build directive macro you can include in your test file TEST_INCLUDE_PATH("..."). Perhaps this plus some command line flags to alter gcc's standard header file #include handling could do the trick for you? See the new documentation on search path for more. Again, :flags handling has changed in 0.32.
Special needs with standard headers come up from time to time. I think 0.32 is able to handle these needs or at least a subset of such needs now. If not, I suspect it can with only a small amount of additional work. Is your project something you could share without confidentiality hiccups? Or, could you share a subset easily anonymized? I'd love to kick the tires on the 0.32 pre-release with a project like yours.
I am going to close the issue for now. I believe the core need has been addressed.
For future reference of anyone coming back to this thread… Ceedling’s preprocessor tool definitions are not really meant to be redefined for other toolchains or really even modified. Unlike all other tool usage in Ceedling, preprocessing is directly tied to the conventions and abilities of gcc and cpp. The options and output are both complex and specific. Alternatives are not currently possible. We hope to revamp the plugin architecture and make it possible to add in some other preprocessing tooling in the future. For now, we've updated the documentation to remove any details of the preprocessing tool defintions and to clearly explain that these tool definitions should not be modified.