On Aug 18, 2016 7:14 PM, "Ivan Vučica" <i...@vucica.net> wrote: > > Stefan: Because otherwise the comment above is lying, no?
Just noticed it. Lesson there is to never drink and email! In any case, I disagree with the comment. > (I don't have a clear idea of what is exactly going on as I'm reading mail on my phone, but the comment speaks for what the author intended to happen. > > Also, when debugging information is needed, you are typically debugging and would preferably want to have the execution to be in order. At least that's my expectation. Rarely - but not never - would I find optimisation + debuginfo useful. I actually think the opposite to be true. Whatever the case, i think GNUstep make should honor the intent of the person compiling the code. If I set -O1 and debug=yes, I would expect the executable to be optimized to level 1, regardless of debugging symbols. A few examples: 1. Distributed binaries: most distributions compile with "-O2 -g" and later remove debugging info from the binary to a different file. This saves space and still allows debugging to happen on production code. 2. Debugging real code: we often see, even on this list, cases where crashes can't be reproduced in debugging mode. To avoid adding another unknown (optimized vs unoptimized code) to the equation, the only thing debug=yes should do is add debugging info. 3. Convention: GNU autotools uses "-O2 -g" if CFLAGS is not given. Most folks compiling their own code are going to expect that to be the case, and doing things differently might cause more confusion. Additionally, I think it is a reasonable expectation that debug=yes isn't going to do anything but add debugging symbols to the binary. Just a few thoughts. > I'm not advocating importing the patch or not, just observing the comment. Someone who is better able to spot and test for side effects should consider the patch's correctness.) Yeah, I derailed the conversation. Sorry. > Giah: interesting observation! Do note that patches are more useful when sent in the standard unified diff format. > > Also, when you write emails, colours are (unless you're pasting syntaxcolored code) just nice decoration, but they are also distracting from the text. There are also no replacement for other plaintext formatting; there is legitimate use for a plaintext-only email client which will not format your colors. Please consider that when decorating your emails. > > > On Thu, 18 Aug 2016, 23:24 Stefan Bidigaray, <stefanb...@gmail.com> wrote: >> >> Why would you want to get rid of the optimization flag? Building with debugging on does not preclude optimization. >> >> >> On Aug 18, 2016 18:12, "Giah de Barag" <g...@crelg.com> wrote: >>> >>> Would you review these two lines intended for insertion at common.make:756 . . . >>> >>> ifeq ($(debug), yes) >>> # Optimization flags are filtered out as they make debugging harder. >>> OPTFLAG := $(filter-out -O%, $(OPTFLAG)) >>> CCFLAGS := $(filter-out -O%, $(CCFLAGS)) >>> ADDITIONAL_FLAGS := $(filter-out -O%, $(ADDITIONAL_FLAGS)) >>> # If OPTFLAG does not already include -g, add it here. >>> ifneq ($(filter -g, $(OPTFLAG)), -g) >>> ADDITIONAL_FLAGS += -g >>> endif >>> >>> . . . without which debug=yes does not get rid of the -O2 flag. >>> >>> >>> _______________________________________________ >>> Gnustep-dev mailing list >>> Gnustep-dev@gnu.org >>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >>> >> _______________________________________________ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnustep-dev
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
