On Thu 02 Nov 2017, Dylan Baker wrote: > Quoting Matt Turner (2017-11-02 10:06:43) > > On Thu, Nov 2, 2017 at 9:51 AM, Michel Dänzer <mic...@daenzer.net> wrote: > > > FWIW, my vote is for debugoptimized: Assertions are enabled and there's > > > debugging information useful for bug reports, but performance should be > > > decent. > > > > If debugoptimized turns on DEBUG, then I don't think performance will > > be decent as that enables paths like nir_validate. Maybe we should > > change debugoptimized to not do that. Not sure. > > > > I think some of the messaging got confused -- autotools does specify > > -g in the default CFLAGS, but that doesn't really mean it's a useful > > debug build. -g -O2 is really a release build, with debugging symbols. > > debugoptimized does turn on DEBUG. Last time I tried (which was a while ago), > if asserts are enabled but DEBUG is not mesa couldn't be compiled, as asserts > used members of structs that only exist when DEBUG is set. Maybe that's a > situation that deserves being revisited.
I vote for debugoptimized, where debuoptimized contains CFLAGS='-g -O2'. The user gets a build that's suitable for everyday use (-O2) and it the user can submit meaningful bug reports (-g). To -DDEBUG or not to -DDEBUG... Since I want to ensure that users with a self-built Mesa have a Mesa that's suitable for everyday use, I think the default build should *not* contain assertions that severely impact performance. So I vote against -DDEBUG; or, at a minimum, we could keep -DDEBUG and somehow disable the slooooooow assertions in debugoptimized. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
