Hello,
On Donnerstag, 8. Januar 2015 16:02:36 CET, Jan Kundrát wrote:
One clarification to this -- the state has always been to
unconditionally inject -O2 into your build flags, including when
the -DCMAKE_BUILD_TYPE=Debug is in effect. I think that you
would hit quite some slowdown, at least i
On Wednesday, 7 January 2015 21:23:32 CEST, Stephan Platz wrote:
Also I do not have any issues with the performance of current
CMAKE_BUILD_TYPE=Debug builds but I also have a quite powerful
system.
One clarification to this -- the state has always been to unconditionally
inject -O2 into your
Hello,
On Mittwoch, 7. Januar 2015 18:48:12 CET, Jan Kundrát wrote:
Opinions?
I vote for combining the user groups to two groups, one with
CMAKE_BUILD_TYPE=Debug for developers and debugging and one
CMAKE_BUILD_TYPE=RelWithDebInfo or Release.
I don't really care whether release build conta
On Wednesday, 7 January 2015 09:25:25 CEST, Pali Rohár wrote:
Problem is that -Wall (or -W) is not standard option. Other
systems (like Windows) are traditionally using slash instead dash
when parsing options. Could be there some problem?
In theory, yes. In practice, even MSVC apparently recog
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 t
On Mittwoch, 7. Januar 2015 09:25:25 CEST, Pali Rohár wrote:
Re debug symbols
Should stay by default.
Another question is: What do you mean by "default" above?
When you "cmake .." w/o further adjustments, this should result in an O2
build.
Whether you'd like to support a build type type tha
On Tuesday 06 January 2015 23:25:39 Thomas Lübking wrote:
> On Dienstag, 6. Januar 2015 18:15:02 CEST, Jan Kundrát wrote:
> > - Report all reasonable warnings.
>
> +1 (for sure)
>
+1
> > Warnings are IMHO quite useful because they can hint about
> > possible problems in the code.
>
> If there'
On Dienstag, 6. Januar 2015 18:15:02 CEST, Jan Kundrát wrote:
- Report all reasonable warnings.
+1 (for sure)
Warnings are IMHO quite useful because they can hint about possible problems
in the code.
If there's a known comflict (where we cannot avoid a warning but know it's
ok) and this gets
(Splitting out from Gerrit.)
So before we go much further in these reviews which are all very much
related, let's use one of them to agree on the general direction.
Here's what I would like to get:
- Report all reasonable warnings. Warnings are IMHO quite useful because
they can hint about p
