On Friday 18 of May 2012, Stephan Bergmann wrote: > On 05/18/2012 04:05 PM, Lubos Lunak wrote: > > On Friday 18 of May 2012, Stephan Bergmann wrote: > >> On 05/16/2012 05:01 PM, Lubos Lunak wrote: > >>> - non-debug/dbgutils (i.e. also the default) -> -O2 > >>> - symbols -> -g (probably even -g1, if this is actually meant for > >>> release builds with debug info sufficient mainly for backtraces) > >>> - debug/dbgutils -> -g, making sure it overrides -g1 from symbols > >>> - explicit C(XX)FLAGS overrides anything > >> > >> ...and, as something of a special case, no -O... at all (instead of the > >> default -O2) for sc under --enable-debug=-sc/? > > > > Yes, but I don't think it's special. The rule, missing in the list > > above, would be 'debug/dbgutils -> optimizations disabled'. So as soon > > as there's --enable-debug, nothing would get -O2, regardless of symbols. > > > > That's actually one more reason why I think -g should be primarily > > controlled by --enable-symbols and not --enable-debug. > > Ah, you wanted --enable-dbgutil to disable -O2, the same way that > --enable-debug does. Had missed that point. Hm, as I said, I prefer my > --enable-dbgutil --disable-debug builds to be -O2.
What is the point of that combination? As far as I can tell --enable-dbgutil is like --enable-debug but for changes that are BIC, so only dbgutil without debug does not make much sense to me. > So if we change > --enable-dbgutil to imply -O0, I'd like to see that changeset also offer > a reliable way to get back -O2. (And I'm not sure having to set > C(XX)FLAGS can be considered reliable enough, given that pre-set > C(XX)FLAGS impact more decisions in our build system than just -O2 vs. > -O0. But maybe I'm asking for too much.) What other (relevant) decisions should be affected by that? -- Lubos Lunak l.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
