On Tuesday, 6 January 2015 23:25:39 CEST, Thomas Lübking wrote:
Occasional -O0 builds on all compilers (to ensure buildability)
could maybe done by the CI?
What we have now are CI runs for each iteration of each patch. While I do
have quite a few CPUs for that, the number is not infinity and the number
of builds multiplies very quickly. That's actually another reason for
enforcing optimized builds -- the CI runs all tests each time, and some of
the benchmarks hit code paths where missing optimizations translate into
more than doubling the test runtime IIRC. I want my CI feedback as fast as
possible.
Can you recall the reporter and ask for such output?
That was from Christian IIRC, and commit
304842de233104093adf7c915612678d8f58729e suggests that. That's all what I
have now.
I'm unsure about the asserts. Do we want them on in release code?
"Depends"
(Q_ASSERT is btw. noop in Release mode builds)
Yes, which is why it's crucial to have all developers either build in a
different mode, or have -UNDEBUG in release builds. The sanest option is
probably -CMAKE_BUILD_TYPE=Debug for developers, *and* that means that
these builds *have* to be optimized, period.
This imo depends on how asserts are used.
For a code-by-contract approach, asserts can be a horrible
overhead (several check in hot loops...)
I believe we use them that way, yeah. I've however sometimes removed the
worst offenders where they were in some *really* hot place.
and also cause useless aborts (what makes users unhappy)
A failed assert is never useless. If the abort wasn't required, then it's a
bug that the assert was left in place (and yup, we've had these bugs, and
will have them in future).
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
