Ceedling V1.0.0 inexplicably sets the macro UNITY_USE_COMMAND_LINE_ARGS

[dbwalker0min]

I've noticed that when I'm running Ceedling 1.0.0 (in verbose mode), the macro UNITY_USE_COMMAND_LINE_ARGS is being defined on the compiler command line, even though I have not set it in project.yml. I may have some settings wrong in project.yml that induce this (I've attached it for your reference).

Debugging this, I found my function was calling main with no arguments, i.e. main(). When Ceedling is run with this macro set, it wants to be called as main(argc, argv), so I made sure to call it this way with argc zero. When I do this, everything runs great.

I'm still left wondering why this macro gets defined.

project.yml.txt

[mkarlesky]

Hi, @dbwalker0min. UNITY_USE_COMMAND_LINE_ARGS is automatically set in a few scenarios. It is there to enable a handful of command line flags for Unity-based test executables. Those flags can, for instance, cause the test executable to only run and report tests that match a name filter. Use of the Ceedling command line option of --test-case will trigger the definition of this symbol so that the command line parameter can be passed through to the test executable. The new backtrace feature also triggers it. After a test executable crash is detected, the backtrace feature runs each test case individually to narrow in on the crash culprit. Doing that requires UNITY_USE_COMMAND_LINE_ARGS. Ceedling's default for :use_backtraice is :simple. Any non-:none backtrace option will trigger the definition of this symbol.

I'm very curious to understand what you are doing and why this is causing a problem for you. If you're using Ceedling for tests you're generating test runners that have main() defined in them. What function of yours is calling main()? Are you in advanced territory where you're running a test executable from within an emulator?

This can be documented better. Until I understand what your specific scenario is I can't develop an opinion on what else might need to change.

[dbwalker0min]

Yes, I'm using an emulator to run the test executable. My code links in a startup file that points to main. I'm certainly no advanced user, but I'm standing on the shoulders of giants. I'm using the structure used in the Udemy course "Interaction Tests, Mocks & Refactoring in Embedded Software," which also uses the qemu emulator.

I am not running ceedling with the --test-case option. I attempted to modify the project.yml file to set :use_backtrace: to none. Below is the pertinent part of the project.yml file:

:project:
  :build_root: test/build
  :release_build: TRUE
  :test_file_prefix: test_
  :use_exceptions: FALSE
  :use_backtrace: none
  :which_ceedling: gem

I've also tried the :use_backtrace: :none with the same result.

When I run ceedling with the --verbosity=99 option, the command lines generated all include -D"UNITY_USE_COMMAND_LINE_ARGS" as part of the GCC command. See below:

arm-none-eabi-gcc -g -O0 -mcpu=cortex-m3 -mthumb -Wall -Wno-address -UUNITY_USE_COMMAND_LINE_ARGS -I"test/support" -I"Core/Inc" -I"Utilities/lpm" -I"Utilities/lpm/tiny_lpm" -I"Utilities/misc" -I"Utilities/sequencer" -I"Utilities/timer" -I"Utilities/trace" -I"Utilities/trace/adv_trace" -I"Utilities" -I"Drivers/CMSIS" -I"Drivers/CMSIS/DSP" -I"Drivers/CMSIS/DSP/DSP_Lib_TestSuite" -I"Drivers/CMSIS/DSP/DSP_Lib_TestSuite/RefLibs" -I"Drivers/CMSIS/DSP/Examples" -I"Drivers/CMSIS/DSP/Examples/ARM" -I"Drivers/CMSIS/DSP/Examples/ARM/arm_variance_example" -I"Drivers/CMSIS/DSP/Source" -I"Drivers/CMSIS/DSP/Source/BasicMathFunctions" -I"Drivers/CMSIS/DSP/Source/CommonTables" -I"Drivers/CMSIS/DSP/Source/ComplexMathFunctions" -I"Drivers/CMSIS/DSP/Source/ControllerFunctions" -I"Drivers/CMSIS/DSP/Source/FastMathFunctions" -I"Drivers/CMSIS/DSP/Source/FilteringFunctions" -I"Drivers/CMSIS/DSP/Source/MatrixFunctions" -I"Drivers/CMSIS/DSP/Source/StatisticsFunctions" -I"Drivers/CMSIS/DSP/Source/SupportFunctions" -I"Drivers/CMSIS/DSP/Source/TransformFunctions" -I"Drivers/CMSIS/Device" -I"Drivers/CMSIS/Device/ST" -I"Drivers/CMSIS/Device/ST/STM32WLxx" -I"Drivers/CMSIS/Device/ST/STM32WLxx/Include" -I"Drivers/CMSIS/Include" -I"Drivers/STM32WLxx_HAL_Driver" -I"Drivers/STM32WLxx_HAL_Driver/Inc" -I"Drivers/STM32WLxx_HAL_Driver/Inc/Legacy" -I"Drivers/STM32WLxx_HAL_Driver/Src" -I"Drivers" -I"generated" -I"Middlewares/Third_Party" -I"Middlewares/Third_Party/LoRaWAN" -I"Middlewares/Third_Party/LoRaWAN/Crypto" -I"Middlewares/Third_Party/LoRaWAN/LmHandler" -I"Middlewares/Third_Party/LoRaWAN/LmHandler/Packages" -I"Middlewares/Third_Party/LoRaWAN/Mac" -I"Middlewares/Third_Party/LoRaWAN/Mac/Region" -I"Middlewares/Third_Party/LoRaWAN/Utilities" -I"Middlewares/Third_Party/RTT" -I"Middlewares/Third_Party/Smc" -I"Middlewares/Third_Party/SubGHz_Phy" -I"Middlewares/Third_Party/SubGHz_Phy/stm32_radio_driver" -I"Middlewares/ePlant" -I"Middlewares/ePlant/Utilities" -I"Middlewares" -I"LoRaWAN/App" -I"LoRaWAN/App/nfc" -I"LoRaWAN/Target" -I"LoRaWAN" -I"nanopb" -I"edendro-lora-fuota-common/Inc" -I"test/build/vendor/unity/src" -D"TEST" -D"STM32WLE5xx" -D"STACK_SIZE=2048" -D"UNITY_EXCLUDE_STDINT_H" -D"UNITY_EXCLUDE_LIMITS_H" -D"UNITY_EXCLUDE_SIZEOF" -D"UNITY_INCLUDE_DOUBLE" -D"UNITY_SUPPORT_TEST_CASES" -D"UNITY_INT_WIDTH=32" -D"UNITY_LONG_WIDTH=32" -D"UNITY_INCLUDE_CONFIG_H" -D"CMOCK_MEM_STATIC" -D"CMOCK_MEM_SIZE=20480" -D"CMOCK_MEM_ALIGN=2" -D"UNITY_USE_COMMAND_LINE_ARGS" -DGNU_COMPILER -g -c "Utilities/misc/stm32_tiny_vsnprintf.c" -o "test/build/test/out/test_serial_to_string/stm32_tiny_vsnprintf.o" -MMD -MF "test/build/test/dependencies/stm32_tiny_vsnprintf.d"

To be clear, modifying the code so main is called with arguments is functional. It's just something I don't quite understand.

[dbwalker0min]

Nevermind. Dumb user error. I was editing the text file copy of my project file. Once I set :use_backtrace: :none it no longer set the macro. I now see that it works properly.
`

[mkarlesky]

@dbwalker0min Great. You figured it out. I'm going to reopen this issue and mark it as documentation to keep it on the to-do list. I think we'll add some logging as well that explains why this symbol or others are being automatically defined. We've started logging problematic configuration combos. I think we can also do something here for when the test fixture is redefined to anything other than default to flag potentially problematic settings like using backtrace.