public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Lyude <lyude@redhat.com>
To: igt-dev@lists.freedesktop.org
Cc: Petri Latvala <petri.latvala@intel.com>, Daniel Vetter <daniel@ffwll.ch>
Subject: [igt-dev] [PATCH i-g-t v3 6/9] meson: Don't allow building with NDEBUG, ever
Date: Wed, 24 Apr 2019 16:20:30 -0400	[thread overview]
Message-ID: <20190424202033.7601-7-lyude@redhat.com> (raw)
In-Reply-To: <20190424202033.7601-1-lyude@redhat.com>

From: Lyude Paul <lyude@redhat.com>

Following some discussion and confusion around whether or not assert()
should be used, it seems the decision has come to "yes, sometimes". To
quote Petri Latvala on the appropriate points to use assert() in lib/:

  However, it's the thought that matters, and this is slightly going off
  on a tangent. Those uses of assert in lib/ are for places where

  1) something is fatally wrong and we need to drop everything and stop
     executing

  2) cannot use igt_assert for it. That's for places where we can say
     "you tried testing your kernel but it has a bug". The lib/ asserts
     are for "IGT has a bug", or in a couple of cases, "your IGT setup
     has a bug".

While we did come to the conclusion that we should possibly consider
introducing a new API to check for bugs with igt (and prevent further
testing if any are found), until then let's at least make sure that
assert() always works where we expect it.

So, accomplsih this by raising an error if b_ndebug isn't set to
'false'. Additionally, run the compile check in lib/check-ndebug.h to
make sure that the user does not have -DNDEBUG set in their CFLAGS,
c_args options, etc.

Signed-off-by: Lyude Paul <lyude@redhat.com>
---
 meson.build | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/meson.build b/meson.build
index e73275dd..bdf02e45 100644
--- a/meson.build
+++ b/meson.build
@@ -3,12 +3,22 @@ project('igt-gpu-tools', 'c',
         default_options: [
           'warning_level=2',
           'c_std=gnu11',
+	  'b_ndebug=false',
         ],
 	license : 'MIT',
 	meson_version : '>=0.46.0')
 
+if get_option('b_ndebug') != 'false'
+	error('Building without -Db_ndebug=false is not supported')
+endif
+
 cc = meson.get_compiler('c')
 
+# Also make sure that the user doesn't have -DNDEBUG defined in their config
+if not cc.compiles(files('lib/check-ndebug.h'), args: get_option('c_args'))
+	error('Building with NDEBUG defined is not supported')
+endif
+
 cc_args = [
 	'-Wbad-function-cast',
 	'-Wdeclaration-after-statement',
-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  parent reply	other threads:[~2019-04-24 20:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24 20:20 [igt-dev] [PATCH i-g-t v3 0/9] Fixes from updating igt packaging in Fedora Lyude
2019-04-24 20:20 ` [igt-dev] [PATCH i-g-t v3 1/9] lib/tests: Fix test failures with meson 0.50.0 Lyude
2019-04-24 20:20 ` [igt-dev] [PATCH i-g-t v3 2/9] Use gettid() wrapper everywhere Lyude
2019-04-24 20:20 ` [igt-dev] [PATCH i-g-t v3 3/9] lib/aux: Typecast gettid() as pid_t Lyude
2019-04-24 20:20 ` [igt-dev] [PATCH i-g-t v3 4/9] meson: Don't redefine gettid if the C library provides it Lyude
2019-04-24 20:20 ` [igt-dev] [PATCH i-g-t v3 5/9] meson: Add .so versioning Lyude
2019-04-24 20:20 ` Lyude [this message]
2019-04-24 20:20 ` [igt-dev] [PATCH i-g-t v3 7/9] lib/igt_core: Just use igt_can_fail() in __igt_run_subtest() Lyude
2019-04-24 20:20 ` [igt-dev] [PATCH i-g-t v3 8/9] Use pkgconfig() macros with dnf in Fedora Dockerfile Lyude
2019-04-24 20:20 ` [igt-dev] [PATCH i-g-t v3 9/9] Update Dockerfile.fedora to Fedora 29 Lyude
2019-04-24 21:14 ` [igt-dev] ✓ Fi.CI.BAT: success for Fixes from updating igt packaging in Fedora (rev2) Patchwork
2019-04-25 10:12 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190424202033.7601-7-lyude@redhat.com \
    --to=lyude@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=petri.latvala@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox