On 13/12/2018 17:26, Jason Ekstrand wrote:
On Thu, Dec 13, 2018 at 5:06 AM Eric Engestrom
<eric.engest...@intel.com <mailto:eric.engest...@intel.com>> wrote:
On Wednesday, 2018-12-12 15:24:25 -0800, Dylan Baker wrote:
> In the autotools discussion I've come to realize that we also
need to talk about
> the -DDEBUG guard. It seems that there are two different uses,
and thus two
> different asks about it:
>
> - Nine (and RadeonSI?) use -DDEBUG to hide generic debugging
> - NIR and Intel (at least) use -DDEBUG to hide really expensive
checks that are
> useful, but necessarily tank performance.
>
> The first group would like -DDEBUG in debugoptimized builds, the
second
> obviously doesn't.
>
> Is the right solution to move the first group being !NDEBUG, or
would it be
> better to split DEBUG into two different defines such as
DEBUG_MESSAGES and
> EXPENSIVE_VALIDATION (paint the bikeshed whatever color you
like), with the
> first for both debug and debugoptimized and the second only in
debug builds?
Replacing DEBUG with !NDEBUG is obviously trivially simpler, but I
think
the right thing would be to split it into !NDEBUG and
EXPENSIVE_VALIDATION
(the color suits me just fine :P), as both solutions satisfy the first
group but only the latter solution satisfies the 2nd group.
I think a first pass might be to simply
s/DEBUG/EXPENSIVE_VALIDATION/ so
that it expresses the intent more clearly, with a prior patch to
convert
Nine and other obvious !NDEBUG candidates, then, later on, some of the
EXPENSIVE_VALIDATION can be promoted to !NDEBUG on a case-by-case
basis.
I think this whole discussion is way over-thinking this. With autools,
we had two options: --enable-debug or not which, as I understand it,
corresponds to release and debug. Great. Now meson adds a new one.
Let's just pick something that makes sense and call it a day; it
really doesn't matter. Anyone who wants more control can just set
their own CFLAGS. Regardless of what we do, we're not really loosing
anything by doing this as people who build Nine today with
--enable-debug are getting an unoptimized build the same as they would
with -Dbuild-type=debug. Users/devs can also always set -Db_ndebug
manually to get the behavior that they want.
I don't know that I have all that strong of a preference as I'm not
likely to use it anyway. On the one hand, the name implies that it's
a debug build only optimized. This is different than CMake's
RelWithDebugInfo which is clearly a release build with debug symbols.
Based on that naming, i'd say we should leave asserts on.
I think the root of the issue is that different developers have tied
way too much stuff to -DDEBUG. The Nine people can add a
-Dnine-logging=true flag that can turn on logging even in release
builds. In the NIR-based drivers, we already have environment
variables to shut off NIR validation to make things go faster even in
debug builds.
--Jason
Hi,
I agree with Jason that there seems to be a multitude of needs and that
it may be hard to handle for all these needs in a simple way.
Devs who want to stress specific parts of their code can indeed use
CFLAGS, and thus there isn't need to have a meson build mode for every
specific need.
However I believe using a debug build option should be all that is
needed for a user to help report bugs. If the user is investigating a
crash, he wants to enable asserts and debug info. He may want to enable
nine logging, etc.
Dev flags may change between releases, while the user would always have
the same debug option to enable all it may need.
I think the autotools way was simple for the user, and the new meson way
should be as simple. 'debugoptimized' is counter-intuitive for an user,
who may expect all the mentioned debug info.
To me debugoptimized should be similar to debug, but with -O2.
Other dev specific debug options can be added with CFLAGS.
Axel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
