Differentiating compiler options between ZDebug and ZRelease build configs with NCS/SES

[variant]

The following questions are in regards to the instructions at nRF_Connect_SDK-modifying-a-sample-application.

In the Windows environment, I am transitioning from using nRF5_SDK_16.0.0 to using

• nRF Connect SDK v1.3.0, with
• SES 4.52
• board nrf52840dk_nrf52840.

1. In the section NRF_Connect_SDK-configuring-build-types, it's not clear to me as to how to set compiler options individually per build configs ZDebug vs ZRelease.

• For example, if we want the ZDebug build to include compiler options like "-g -O0 -DDEBUG" but the ZRelease build to instead include compiler options like "-O3 -DNDEBUG", how do we do this?

The figure in maintaining-cmakelist-txt-in-ses shows how to set compiler defines and options, but those options would apply to both ZDebug and ZRelease, as far as I can tell.

Furthermore, when I built nrf_desktop for ZDebug and then ZRelease to see what happens, I saw in the build outputs that both builds had "-O2" and "-g" compiler options.

• There were very few differences between those two build outputs other than things like ZDebug had an include path for rtt but ZRelease did not, as you would expect when you look at the diff between the debug/release .conf files.
• I was hoping to see at least some optimization differences, or at least a "-DDEBUG" difference, between the two build outputs to help me figure out the answer to this question.

2. In my opinion, the section selecting-a-build-type-in-ses or the previous section should indicate that the SES menus "Build/Build Configuration" and "Build/Set Active Build Configuration" are not applicable with this SDK. I originally was looking for ZDebug and ZRelease options to show up in those menus after following the instructions in the previous section.

3. In the instruction on how to set the CONF_FILE variable for the build configs (see step 2 in Creating build type files), doesn't the path "${CMAKE_CURRENT_SOURCE_DIR}" need to be in the CONF_FILE setting, as in:

if (CMAKE_BUILD_TYPE)

  set(CONF_FILE "${CMAKE_CURRENT_SOURCE_DIR}/app_${CMAKE_BUILD_TYPE}.conf")

endif()

• I found this path addition necessary. Without that path, the conf file was not found by cmake, as I learned when using assert_exists(CONF_FILE).

4. Is there something special with the names ZDebug and ZRelease vs traditional build config names Debug and Release?

• I assume there is a link that describes these names, but I can't find one.  If you can provide a link and it's for Zephyr in general, is there any additional meaning here for nRF usage in the SDK not described in that link?

5. Is building with the command line, and perhaps just using SES for a debugger tool, the easier way to go with this SDK?

In general, I am pleased with Nordic documentation, but perhaps I am not finding the right places to look for the questions above.

[Amanda Hsieh]

Hi Mike,

For example, if we want the ZDebug build to include compiler options like "-g -O0 -DDEBUG" but the ZRelease build to instead include compiler options like "-O3 -DNDEBUG", how do we do this?

You can edit prj.conf and add "NO_OPTIMIZATIONS=Y" to set compiler optimizations as -O0 or "DEBUG_OPTIMIZATIONS=Y" to set the compiler optimizations as -Og. Please see <choice: Optimization level>.

 

I was hoping to see at least some optimization differences, or at least a "-DDEBUG" difference, between the two build outputs to help me figure out the answer to this question.

 If you want to see the difference between compile optimization, you should see <choice: Optimization level>.

2. In my opinion, the section selecting-a-build-type-in-ses or the previous section should indicate that the SES menus "Build/Build Configuration" and "Build/Set Active Build Configuration" are not applicable with this SDK. I originally was looking for ZDebug and ZRelease options to show up in those menus after following the instructions in the previous section.

See the Selecting a build type in SES section on how to build the project with the app_ZDebug .conf and app_ZRelease.conf. 

3. In the instruction on how to set the CONF_FILE variable for the build configs (see step 2 in Creating build type files), doesn't the path "${CMAKE_CURRENT_SOURCE_DIR}" need to be in the CONF_FILE setting, as in:

I will report it. 

4. Is there something special with the names ZDebug and ZRelease vs traditional build config names Debug and Release?

 The nRF Desktop does not use a single prj.conf file. Configuration files are provided for different build types for each supported board as here as the Creating build type files section described. If you take a look at configuration/nrf52840gmouse_nrf52840, you could see the files named with ZRelease and ZDebug as nRF Desktop build types describe:

ZRelease – Release version of the application with no debugging features. 

ZDebug – Debug version of the application; the same as the ZRelease build type, but with debug options enabled.

Comparing the app_ZDebug.conf and app_ZRelease.conf, you could see what debug options are enabled.

 

is there any additional meaning here for nRF usage in the SDK not described in that link?

 Please see build types are available for various boards in nRF Desktop in the nRF Desktop build types.

 

5. Is building with the command line, and perhaps just using SES for a debugger tool, the easier way to go with this SDK?

SES also can build the project. It depends on your habit. 

-Amanda H.

[variant]

Thanks Amanda.

1. I understand your reply, and it makes perfect sense.  I'm trying this out on the central_uart sample, but I'm not seeing any affect yet in the build output.  I'll double check my steps tomorrow and provide more details if I am still unsuccessful.

As an aside, I think it would helpful in the section maintaining-cmakelist-txt-in-ses, where it says "In the window that is displayed, you can define compilation options for the project", that someone adds a note there that you can set the compiler optimization levels (which to me are still compilation options) in the conf file, as you explained.   That is, that "window" they are talking about there is not the only place you can define compilation options. You can also do so in the conf files. Just a suggestion. 

2. You pointed to the same place that I pointed to.  I was just making a suggestion that that section could possibly be more helpful with the information I suggested to add.

3. Thanks.  By the way, my discovery here was for the central_uart sample.

4. I see.  So it seems that the Z (for Zephyr) is just a convention, as in ZDebug/ZRelease.  So in my own projects, would there be any hidden problem if I go unconventional (not that I would) and use names app_debug.conf and app_release.conf instead of app_ZDebug.conf and app_ZRelease.conf, as long as I account for those names in the CMakeLists.txt?

[Amanda Hsieh]

Hi Mike, 

It seems that the config files are not used. You can modify like this:

# Define configuration files.
set(CONF_FILE "configuration/${BOARD}/app_${CMAKE_BUILD_TYPE}.conf")

#########################################
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(central_uart)

# NORDIC SDK APP START
target_sources(app PRIVATE
  src/main.c
)
# NORDIC SDK APP END

zephyr_library_include_directories(${CMAKE_CURRENT_SOURCE_DIR})

I also modify central_uart as this project central_uart_build_type.zip to use build type, and it can work as expected in west build and Segger.  

-Amanda H.

[variant]

In my comment way above (it says 21 days ago right now), I wrote:

In CMakeLists.txt, I added this in the Nordic SDK App section:

if (CMAKE_BUILD_TYPE) 
   set(CONF_FILE "${CMAKE_CURRENT_SOURCE_DIR}/app_${CMAKE_BUILD_TYPE}.conf")
endif()
message(STATUS "NOTE: CMAKE_BUILD_TYPE: ${CMAKE_BUILD_TYPE}")
message(STATUS "NOTE: CONF_FILE: ${CONF_FILE}")

Then I showed in that old comment that my status messages inserted above showed up in the output:

-- NOTE: CMAKE_BUILD_TYPE: ZDebug
-- NOTE: CONF_FILE: C:/ncs/v1.3.0/nrf/samples/bluetooth/central_uart/app_ZDebug.conf

So I'm not sure what you are doing differently than what I already did.  My output above shows that CMAKE found the CONF_FILE.

Is the issue where the location that we put the conf file?

[Amanda Hsieh]

Hi Mike,

variant said:

Is the issue where the location that we put the conf file?

It might be. I use your code in the CMakeLists.txt and modify the location as:

if (CMAKE_BUILD_TYPE) 
   #set(CONF_FILE "${CMAKE_CURRENT_SOURCE_DIR}/app_${CMAKE_BUILD_TYPE}.conf")
   set(CONF_FILE "configuration/${BOARD}/app_${CMAKE_BUILD_TYPE}.conf")
   message(STATUS "NOTE: CMAKE_BUILD_TYPE: ${CMAKE_BUILD_TYPE}")
   message(STATUS "NOTE: CONF_FILE: ${CONF_FILE}")
endif()

It works as expected. Try this central_uart_build_type_0717.zip

-Amanda H.

  

[variant]

Hi Amanda,

From my experiments, I’ve determined that

• It does matter where we place the CONF_FILE assignment in CMakeLists.txt.
• It does not matter where we actually put the .conf file within the project.

In other words:  The .conf file like app_ZRelease.conf can be placed anywhere in the project, so the CONF_FILE value itself doesn’t matter.  But it does matter where in CMakeLists.txt that the CONF_FILE assignment is placed.

With the first bullet being met, I was able to control the compile optimizations specified in the .conf file.

Per the first bullet:  In CMakeLists.txt, the CONF_FILE setting must be before the find_package for Zephyr, as in:

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-BSD-5-Clause-Nordic
#

cmake_minimum_required(VERSION 3.8.2)

# changes to specify CONF_FILE
if (CMAKE_BUILD_TYPE)
  set(CONF_FILE "arbitrary/app_${CMAKE_BUILD_TYPE}.conf")
endif()
message(STATUS "NOTE: CMAKE_BUILD_TYPE: ${CMAKE_BUILD_TYPE}")
message(STATUS "NOTE: CONF_FILE: ${CONF_FILE}")
# end CONF_FILE changes

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(central_uart)

 

Note in the above that the actual location of the .conf file is in an arbitrary place (per the second bullet), under a directory called “arbitrary”, which is under the project directory central_uart.  I could have just as well put the .conf file in the central_uart top-level directory, as in: 

set(CONF_FILE "app_${CMAKE_BUILD_TYPE}.conf")

 Do you agree?

The advantage of using CMAKE_CURRENT_SOURCE_DIR when specifying the value of CONF_FILE in CMakeLists.txt is that you can later use an assert_exists() to make sure that the .conf file pointed to by CONF_FILE exists.  I was not able to get the assert_exists() to work properly without using CMAKE_CURRENT_SOURCE_DIR to set the path in the CONF_FILE value. 

Here's an example using CMAKE_CURRENT_SOURCE_DIR in CONF_FILE, and then using the assert_exists(), which is at the end of the snippet: 

if (CMAKE_BUILD_TYPE)
  set(CONF_FILE "${CMAKE_CURRENT_SOURCE_DIR}/app_${CMAKE_BUILD_TYPE}.conf")
endif()
message(STATUS "NOTE: CMAKE_BUILD_TYPE: ${CMAKE_BUILD_TYPE}")
message(STATUS "NOTE: CONF_FILE: ${CONF_FILE}")

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(central_uart)
assert_exists(CONF_FILE)

Also, as a reminder, mainly for my benefit: Whenever you change the CONF_FILE value in CMakeLists.txt, you must re-open the solution in SES with the Clean Build Directory checked for that change to take affect.  If you don’t change the CONF_FILE value in CMakeLists.txt but change a value within the .conf file (e.g., change the value of CONFIG_SPEED_OPTIMIZATIONS in app_ZRelease.conf), you must re-open the solution in SES, but you don’t need to have the Clean Build Directory checked.

[Amanda Hsieh]

Hi Mike, 

Sorry for the delay. The support staff is reduced during the summer holidays, and you may experience delayed answers.

I agree with you all, and thanks for the nice sharing detail.  

You can put the .conf file like app_ZRelease.conf anywhere in the project only if the CONF_FILE variable could be set in the CMakeLists.txt, and any modification of setting in .conf, .proj, .yaml, .overlay, etc., need to reopen the SES to source them again. 

-Amanda H. 

[variant]

Thanks for your help, Amanda.  You can close this ticket.