RE: Difference between public configurations (release & debug) and private configurations (common)

awneil — Fri, 05 Jul 2019 09:13:19 GMT

SES User Manuals:

https://download.segger.com/SES/segger_embedded_studio_manual.pdf

https://www.segger.com/downloads/embedded-studio/EmbeddedStudio_Manual

The relevant part of the SES online documentation is here:

https://studio.segger.com/ide_project_configurations.htm

Documentation is also available within the IDE itself:

SES forum: https://forum.segger.com/index.php/Board/9-SEGGER-Embedded-Studio-related/

Note that this has nothing specifically to do with Nordic; it is a standard feature of SES.

[quote userid="15909" url="~/f/nordic-q-a/49412/difference-between-public-configurations-release-debug-and-private-configurations-common/196743"]I assume that what you are talking about is build configurations? [/quote]

Yes, it is.

The "public" configurations are the ones that you can actually build.

The "private" configurations can't be built - they are used to define stuff which is inherited by the "public" configurations.

[quote userid="81222" url="~/f/nordic-q-a/49412/difference-between-public-configurations-release-debug-and-private-configurations-common"]When should we use public configurations[/quote]

Apart from Debug & Release, another common use for 'Configurations' is to build different variants of a project; eg, one to run on a Dev Kit, and one to run on your custom hardware.

As Andy suggests, the concept of "Configurations" is pretty much universal to all IDEs - not just SES.

However, I haven't seen another one that allows this hierarchy of inheriting "common" settings. It is extremely useful!

RE: Difference between public configurations (release & debug) and private configurations (common)

Andy — Fri, 05 Jul 2019 08:37:35 GMT

I don't use SES, I use Eclipse. I assume that what you are talking about is build configurations? If that's the case, you can use them to compile "different versions" of the same project without making any actual changes in code.

For example, maybe you want logging enabled in the Debug config and logging disabled in the Release config. You can define some conditions for the preprocessor to compile code differently for different configurations, e.g. you can have DEBUG in your preprocessor definitions and wrap code with #ifdef DEBUG sentences.

You can also have different build steps in different configurations - for example you could have the Release config generate DFU zip files automatically when you compile and so on.