On 2014/11/28 10:12, Mike Hommey wrote:
Hi,
A year ago, when unified compilation was introduced to speed up builds,
a couple issues were raised and we conservatively restricted them out
of aurora/beta/release/esr.
A year later, it's time to revisit this decision, and since afaik we
haven't had problems specific to unified compilation on nightlies,
including for crash reports, we can assume the issues are either gone
or didn't exist in the first place (one problem that comes to mind is
bug 943695, and it probably isn't a problem in practice, although weird)
I know a lot of people have burned non-unified builds now and then.
That's an annoyance and a distraction for getting things done. If
unified compilation rides up to beta and we don't see significant
problems, I think we can disable all periodic non-unified builds
and make the few builds that are always non-unified unified again (a few
debug builds are this way).
The downside from doing so, though, is that non-unified build *will*
be broken, and code "purity" (right includes in the right sources,
mostly) won't be ensured. Do you think this is important enough to keep
non-unified builds around?
Mike
Can we debug unified build binary using gdb under Unixens?
I mean the unified source is gone by the time the binary runs,
and I wonder what the gdb would do to print the "source" lines.
Of course, if gdb gets confused, we can create a non-unified binary to
use source code debugging, etc. [I am talking about C++ side of the
debugging.]
But, if gdb gets confused,
then not supporting non-unified build for C++ debugging
sounds tough. People's opinion may vary, but I have seen many issues
with C++ binary and so am not comfortable dropping non-unified build,
if gdb and other debugger aids get confused.
Of course, producing end-user binary wins by using unified compilation.
I agree.
TIA
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
