On Tuesday, 2018-07-17 16:09:33 +0100, Eric Engestrom wrote:
> On Tuesday, 2018-07-17 10:26:49 -0400, robdcl...@gmail.com wrote:
> > On Tue, Jul 17, 2018 at 10:05 AM, Eric Engestrom
> > <eric.engest...@intel.com> wrote:
> > > On Tuesday, 2018-07-17 09:01:46 -0400,
> > > mesa-dev-boun...@lists.freedesktop.org wrote:
> > >> On Mon, Apr 16, 2018 at 5:19 PM, Dylan Baker <dy...@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.steff...@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
Just tried, and meson does accept this syntax; however, I also just
realized it doesn't have the behaviour you think: this is the
default_options list, which gets stored by `meson setup` and then
overridden by all the things passed in, like `--buildtype=release` or
`-D buildtype=release`.
This means only the value when running `meson setup` counts, and since
we're setting the default `buildtype` literally right before on the same
line, the result will always be `b_ndebug=true` (or `false` if you write
the condition as `get_option('buildtype').startswith('debug')`),
ignoring the buildtype set by the user.
`if-release` on the other hand is evaluated whenever needed, which means
if the user decides to override the default buildtype to set it to
`release` for instance, this will be taken into account and will give
the expected result depending on the buildtype actually set by the user.
> 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.
>
> >
> > 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-boun...@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@lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
