compiler.warning_flags activates debug code

[lacklustrlabs]

I would expect the produced binary to remain the same, regardless of the value of {compiler.warning_flags} Wouldn't {build.flags.optimize} be a more appropriate place to put the -DDEBUG_LEVEL stuff?

in platform.txt:

compiler.warning_flags=-w -DDEBUG_LEVEL=DEBUG_NONE
compiler.warning_flags.none=-w -DDEBUG_LEVEL=DEBUG_NONE
compiler.warning_flags.default=-DDEBUG_LEVEL=DEBUG_NONE
compiler.warning_flags.more=-Wall -DDEBUG_LEVEL=DEBUG_FAULT
compiler.warning_flags.all=-Wall -Wextra -DDEBUG_LEVEL=DEBUG_ALL

And why is -g always active? Specially when only the last item in the {build.flags.optimize} dropdown list mentions -g. I know Arduino does the same thing, and that the binary size doesn't seem to change when -g is removed. I'm just curious. compiler.cpp.flags=-c -g {build.flags.optimize} {compiler.warning_flags} -std=g++11 ....

[RickKimball]

If you want to debug your release version, and the -g isn't in there you can't see any symbols. Please don't even consider removing this.

[rogerclarkmelbourne]

I've not looked at binary sizes with and without the -g option.

But, IMHO it would be too complicated to have a Release and Debug option , as this would need to be on yet another drop down menu, which would need to be defined for all the variants.

[lacklustrlabs]

Can't the existing {build.flags.optimize} dropdown be expanded with combinations of optimization and debug/release? E.g:

Smallest, debug (default)
Smallest, release
....
Fastest -O3, release

It might be a long list, since it is already combined with LTO. An alternative could be to only enable DEBUG_LEVEL on the last item in {build.flags.optimize}, since it is already named "Debug (-g)"

[RickKimball]

Why don't you make the changes and create a pull request @lacklustrlabs

[lacklustrlabs]

I have zero experience with IDE internals, but I could give it a try. Just trying to figure out if you think this is something that's really needs fixing. It could just as well be my OCD acting up :smiley:

[RickKimball]

I think it would be a great experience to understand what you are asking to be done. There are 3 platforms, UNIX, Windows and OSX. To accomplish your change you need to test on all 3. In addition, there are at least 4 must test boards. So you need to make the change and make sure it works for those boards on all 3 operating systems without breaking anything that currently works.

My point was I don't think you understand the amount of work you asking to be done and what little gain it actually provides. However, the risk involved in the change is quite high.

[lacklustrlabs]

@RickKimball Well, it does not seem too difficult,

platform.txt:

compiler.warning_flags=-w
compiler.warning_flags.none=-w 
compiler.warning_flags.default= 
compiler.warning_flags.more=-Wall 
compiler.warning_flags.all=-Wall -Wextra

boards.txt:

-- Optimizations
mapleMini.menu.opt.osstd=Smallest (default)
mapleMini.menu.opt.osstd.build.flags.optimize=-Os -DDEBUG_LEVEL=DEBUG_FAULT
mapleMini.menu.opt.osstd.build.flags.ldspecs=
mapleMini.menu.opt.oslto=Smallest Code with LTO
mapleMini.menu.opt.oslto.build.flags.optimize=-Os -flto -DDEBUG_LEVEL=DEBUG_FAULT
mapleMini.menu.opt.oslto.build.flags.ldspecs=-flto
mapleMini.menu.opt.o1std=Fast (-O1)
mapleMini.menu.opt.o1std.build.flags.optimize=-O1 -DDEBUG_LEVEL=DEBUG_NONE
mapleMini.menu.opt.o1std.build.flags.ldspecs=
mapleMini.menu.opt.o1lto=Fast (-O1) with LTO
mapleMini.menu.opt.o1lto.build.flags.optimize=-O1 -flto -DDEBUG_LEVEL=DEBUG_NONE
mapleMini.menu.opt.o1lto.build.flags.ldspecs=-flto
mapleMini.menu.opt.o2std=Faster (-O2)
mapleMini.menu.opt.o2std.build.flags.optimize=-O2 -DDEBUG_LEVEL=DEBUG_NONE
mapleMini.menu.opt.o2std.build.flags.ldspecs=
mapleMini.menu.opt.o2lto=Faster (-O2) with LTO
mapleMini.menu.opt.o2lto.build.flags.optimize=-O2 -flto -DDEBUG_LEVEL=DEBUG_NONE
mapleMini.menu.opt.o2lto.build.flags.ldspecs=-flto
mapleMini.menu.opt.o3std=Fastest (-O3)
mapleMini.menu.opt.o3std.build.flags.optimize=-O3 -DDEBUG_LEVEL=DEBUG_NONE
mapleMini.menu.opt.o3std.build.flags.ldspecs=
mapleMini.menu.opt.o3lto=Fastest (-O3) with LTO
mapleMini.menu.opt.o3lto.build.flags.optimize=-O3 -flto -DDEBUG_LEVEL=DEBUG_NONE
mapleMini.menu.opt.o3lto.build.flags.ldspecs=-flto
mapleMini.menu.opt.ogstd=Debug (-g)
mapleMini.menu.opt.ogstd.build.flags.optimize=-Og -DDEBUG_LEVEL=DEBUG_ALL
mapleMini.menu.opt.ogstd.build.flags.ldspecs=

(repeat copy & paste at the *.build.flags.optimize line for each board..)

None of these changes are host platform specific, so if it works for one OS the others should be good too.

The DEBUG_LEVEL for each optimization levels are just examples.

But you're right. I simply can't verify this on every board and every OS. Specially as I only own a few Maple Minis and only use Linux and OSX.

I not even sure that this whole endeavor is worth it, maybe it's more important to focus on stuff that's actually broken/missing.

[RickKimball]

I not even sure that this whole endeavor is worth it, maybe it's more important to focus on stuff that's actually broken/missing

There you go

[rogerclarkmelbourne]

I don't think anyone has explained what the benefit is.

Is the code smaller without -g

[lacklustrlabs]

Technically -g should always make the binary large by adding a debugging symbol table, but last time I checked (stm32) it did not matter one byte. What's strange is that -g is always active for Arduino AVR - an environment where we frequently have to fight for the last byte of flash memory and where 99.99% (my guesstimation) of the sketches won't see the inside of a debugger.

However, -g is not really the topic of this issue, it was just a side note. The issue is the -DDEBUG_LEVEL=*** macro.