On Mon, Apr 8, 2019 at 5:50 AM, Kalev Lember <kalevlember@xxxxxxxxx>
wrote:
I agree as well. Please don't override -Db_ndebug in distro-wide
%meson
macro and instead move the override to mesa packaging if it's needed
there.
Well hold up. -Db_ndebug defaults to if-release... right? We have only
changed the behavior for plain builds (distro builds) to match release
builds? So any package that has ever tested a release build would
already know to expect assertions to be disabled, and the only broken
packages are those that have never tested a release build?
I see three options:
- Plain builds should match the behavior of release builds, and Fedora
plain builds should match the behavior of upstream plain builds. This
is what we briefly had but just reverted. (Option one)
- Upstream plain builds should be really completely plain. Fedora can
either add on -Db_ndebug=true or not (options two and three). This
makes less sense to me because -Db_ndebug is really special, not like
other compiler flags.
I don't think it's right to say "NDEBUG should be off by default
because that's how it is with Autotools" since we're not Autotools
anymore, we should decide something that makes sense for meson, based
on meson semantics and meson expectations and in coordination with
meson upstream. E.g. I see you (Igor) reverted the RPM macro change,
but that was just the bandaid over the default behavior of if-release,
which is actually still changed, right? It's unclear to me what the
default value of -Db_ndebug is due to underdocumentation, but if it's
if-release then this change is just going to reappear again in the next
version of meson, right?
Michael
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx