On Mon, Apr 8, 2019 at 5:50 AM, Kalev Lember <kalevlem...@gmail.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to