[Mesa-dev] [PATCH 1/3] meson: Define NDEBUG for non-debug-builds

[Rob Clark]

On Tue, Jul 17, 2018 at 11:09 AM, Eric Engestrom
<eric.engestrom at intel.com> wrote:
> On Tuesday, 2018-07-17 10:26:49 -0400, robdclark at gmail.com wrote:
>> On Tue, Jul 17, 2018 at 10:05 AM, Eric Engestrom
>> <eric.engestrom at intel.com> wrote:
>> > On Tuesday, 2018-07-17 09:01:46 -0400, mesa-dev-bounces at lists.freedesktop.org wrote:
>> >> On Mon, Apr 16, 2018 at 5:19 PM, Dylan Baker <dylan at pnwbakers.com> wrote:
>> >> > Quoting Jan Alexander Steffens (heftig) (2018-04-14 10:23:20)
>> >> >> This is for parity with autotools. We were suddenly getting assertion
>> >> >> failures after switching to meson, see [1].
>> >> >>
>> >> >> [1]: https://bugs.archlinux.org/task/58218
>> >> >>
>> >> >> Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens at gmail.com>
>> >> >> ---
>> >> >>  meson.build | 2 ++
>> >> >>  1 file changed, 2 insertions(+)
>> >> >>
>> >> >> diff --git a/meson.build b/meson.build
>> >> >> index a4dfa62255..931e0389e6 100644
>> >> >> --- a/meson.build
>> >> >> +++ b/meson.build
>> >> >> @@ -705,6 +705,8 @@ endif
>> >> >>  # Define DEBUG for debug builds only (debugoptimized is not included on this one)
>> >> >>  if get_option('buildtype') == 'debug'
>> >> >>    pre_args += '-DDEBUG'
>> >> >> +else
>> >> >> +  pre_args += '-DNDEBUG'
>> >> >>  endif
>> >> >>
>> >> >>  if get_option('shader-cache')
>> >> >> --
>> >> >> 2.16.2
>> >> >
>> >> > NAK.
>> >> >
>> >> > meson has -Db_ndebug for controlling NDEBUG, which is done separately from
>> >> > optimization levels, this is in our documentation as well as the meson
>> >> > documentation. For builds without asserts, set b_ndebug=true.
>> >> >
>> >>
>> >> Is it possible to make b_ndebug default to true for release builds?
>> >> That would be far less surprising..
>> >
>> > Since 0.45 (we support 0.44.1 right now, so we would need to bump),
>> > b_ndebug is no longer a boolean, but now accepts `if-release` as well.
>> >
>> > If that's the preferred solution, I can send this patch:
>> > ----8<----
>> > diff --git a/meson.build b/meson.build
>> > index c62cdd0e395259ec984e..eb90f4cf9b265435fb19 100644
>> > --- a/meson.build
>> > +++ b/meson.build
>> > @@ -25,8 +25,8 @@ project(
>> >      [find_program('python', 'python2', 'python3'), 'bin/meson_get_version.py']
>> >    ).stdout(),
>> >    license : 'MIT',
>> > -  meson_version : '>= 0.44.1',
>> > -  default_options : ['buildtype=debugoptimized', 'c_std=c99', 'cpp_std=c++11']
>> > +  meson_version : '>= 0.45',
>> > +  default_options : ['buildtype=debugoptimized', 'b_ndebug=if-release', 'c_std=c99', 'cpp_std=c++11']
>> >  )
>>
>> is something like:
>>
>> default_options : [(get_option('builttype') == 'debug') ?
>> 'b_ndebug=false' : 'b_ndebug=true', ...]
>>
>> something that is possible in meson?
>
> I don't think this is possible in meson (I'll have a try later), but
> fyi you can see the logic of `if-release` there:
> https://github.com/mesonbuild/meson/blob/master/mesonbuild/compilers/compilers.py#L367
>
> It's turning it on for `release`, not off for `debug`, which is subtly
> different.

hmm, that actually means it would default to off for debugoptimized ..
which is slightly unfortunate when you want debug syms but otherwise
as close as possible to release build.. although maybe this is a niche
use-case that is more interesting to developers, than end users.

I'd started converting NDEBUG over to DEBUG, but since it is sometimes
useful to have a build w/ debug syms but not all the asserts and
expensive checks, maybe I should drop that..

BR,
-R


>
>>
>> If not, I'd vote for b_ndebug=if-release.. even if we postpone it
>> until we bump meson_version for other reasons.
>
> It's not a very large bump (it's literally the next release), so it
> might be ok to do now; otherwise, we can just leave this patch sit for
> a few months.
>
>>
>>
>> >  cc = meson.get_compiler('c')
>> > ---->8----
>> >
>> > Dylan, thoughts?
>> >
>> >
>> > PS:
>> > Rob, your emails are still appearing as
>> >   From: mesa-dev-bounces at lists.freedesktop.org
>> > You might want to change this so people know it's you, and can reply
>> > to you directly :)
>>
>> daniels looked at this a while back.. I don't remember the details but
>> it seems like this is happening on intel's mail server.  Not entirely
>> sure why it picks on me, but also not sure I can do much about it.
>>
>> /me shrugs
>
> I didn't think to check, but you're right, it's only on the intel
> server; my personal email got the right email headers.
> Really weird how intel's server only butchers *your* emails too.
>
>>
>> BR,
>> -R
>>
>>
>> >>
>> >> BR,
>> >> -R
>> >> _______________________________________________
>> >> mesa-dev mailing list
>> >> mesa-dev at lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev