How to add preprocessor macros in VS code with NCS.

[Frikkie Badenhorst]

Hi there,

We are quite new to Zephyr. We are currently porting our existing app onto Zephyr as a test. We are currently using NCS 2.5.1

So for our existing application running in IAR, we have different build configurations. The one build configuration is "debug", in which serial logging and other debugging tools is enabled. The other build configuration is release, which is optimized and does not include debugging tools like serial logging in the build (does not configure the uart or use it ever).

For the different build configurations, we then provide different preprocessor macros, for example RELEASE for the release build and DEBUG for the debug build. In the code then, we can use the following:

 #ifndef RELEASE
    //Do something for DEBUG build
 #else
    //Do something for RELEASE build
 #endif

\

However we cant seem to provide preprocessor macros, unless we are overlooking it. I cant imagine that it is not possible to do this. So in the above statement, the #else clause is always true since RELEASE can never be defined.

Does not seem to be easy to have different project settings for different build configurations, as changing the proj.conf and cmakelists.txt file seems to change settings project wide (on all build configs).

Regards,

Frikkie

[runsiv]

Sorry for the late update. I don't really have any definitive answer. 

"However it seems that this is added project wide for all build configurations. So lets say we have 2 build configs, build x and y. In build x, we want to add_compile_definitions(ENALBED), however in build y, we do not want it added." 

I would say that the best way to solve this is to create multiple build configuration in VScode where you set in the build configuration the extra defines you want in the code with the 

-DVAR...=...

. That was recommendation i got at least, the drawback is that it could be easily lost. 

it is also possible to include a file from CMakeList.txt but I could not see how to tie to different builds right now. 

I guess it could be possible to have multiple Cmakelist.txt but multiple cmakelist are normally for example example used for when you create  out of tree drivers. 

It is also possible to use custom Kconfig options as described here https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/build/kconfig/tips.html that could also be an option. To include an additional config file as part of the build configuration. 

Regards

Runar

[liteyear]

Phwoah, spent a couple of unexpected days re-inventing the wheel here. Loooooong story short, here's what I'm now using to define preprocessor macros:

1. At the bottom of my CMakeLists.txt I have the line:
   1. include(${CMAKE_CURRENT_SOURCE_DIR}/private.cmake OPTIONAL) 
2. I then have an (optional) private.cmake file in the same directory, which can be ignored from source control.
3. In that file I'm free to define developer-specific configuration, and even secrets.
4. In particular, I use this is create preprocessor defines:
   
   1. target_compile_definitions(app PRIVATE NAME_OF_DEFINE=value)
   2. which appears to the preprocessor as #define NAME_OF_DEFINE value

There's a lot I hate about this bastardisation of a basic concept, but it works, and has these nice features:

1. You can use quotes literally, to make the define a C string. Eg. NAME="value" becomes #define NAME "value"
2. Escaping special characters like $ is automagic - no sign of shell expansion (however, be careful of Escape Sequences (\x) and Variable References (${var}) - they might still be evaluated).
   
3. You can use anything else that CMake has available, too.
4. You can use the file as you see fit - version it, share it, hide it, keep variations, etc. This is much easier than the Build Configurations in VSCode, which sent me batty with all their mysterious parsing and regular corruption.
5. You can combine it with, say CMake's option command, and turn it off and on by setting an "Extra CMake argument" like -DWITH_FEATURE_A=ON in the Build Configuration.  See here for more details.
   1. Note I haven't tried this. The Extra CMake arguments setting is difficult to work with, but given how little is required of it it would probably work fine in this case. FWIW, my needs were a bit different and after a long search I went down the build type path instead to give me some Build Configuration based settings. It's a bit hard to imagine how this could be tied into CMakeLists.txt.

Before landing on this implementation I tried all the suggestions in this thread, and also considered CONFIG_COMPILER_OPT. But everything else turned out nasty.