Skip to content

support for debug/release builds in Arduino IDE 2.x  #2159

Closed
@m-mcgowan

Description

@m-mcgowan

This is a feature request (which I'm happy to implement) and a request for comments.

Background

Arduino IDE 2.x supports debugging, and with that, has a new menu option Sketch > Optimize for Debugging.

This looks like a convenient way to enable debugging builds with symbols from within the IDE and provides a standard means of compiling a debug build with the CLI.

Under the hood

The Optimize for Debugging option sets the compiler.optimization_flags placeholder from either compiler.optimization_flags.debug or compiler.optimization_flags.release according to the setting chosen. (The debugging section in the platform spec explains this more fully.)

boards.txt currently defines menus for the optimization level, and whether symbols and/or core logs are compiled in. The overlap in functionality between these existing selection and the new "Optimize for Debugging" selection may need to be resolved.

Possible Implementation

As a starting point platform.txt would have two new placeholders defined, corresponding to the flags used for debug and release builds:

compiler.optimization_flags.debug=-g
compiler.optimization_flags.release=-DNDEBUG

The build environment then sets compiler.optimization_flags from either of these two, which we could propagate via compiler.extra_flags:

compiler.extra_flags=-mcpu={build.mcu} {compiler.optimization_flags} {...etc...}

With this in place, the Debug setting always includes debug symbols, and the Release setting does not include system logs, irrespective of the setting of the Debug symbols and core logs menu item. This seems to be the least element of surprise and does "the right thing" for debug and release builds, although it may not be obvious to users that the Optimize for Debugging menu selection takes precedence over the Debug symbols and core logs menu selection when it comes to enabling/disabling core logs.

Alternatively, the compiler.optimization_flags.release value could be left empty, which would mean that a release build uses the selection from Debug symbols and core logs exclusively, while the debug build always contains symbols, plus core logs when selected.

The latter approach seems somewhat "dangerous" in that it puts the onus on the user to be certain to deselect core logs in a release build.

If I were asked to make the choice, I would lean more towards the first approach with release builds explicitly excluding core logs, simply because it feels more in line with what a developer would expect for a release build, but that's just my casual suggestion. The community here may see other alternatives, or have good reasons to prefer the second approach, which I look forward to learning about and discussing.

Once we've established the most desirable way forward, I would be happy to make the changes needed and submit a PR.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions