public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [RFC PATCH v3 2/2] Start libclang based analyzer and TEST() check
Date: Tue, 15 Jun 2021 12:44:13 +0200	[thread overview]
Message-ID: <YMiEfQfujl9lJ1lZ@pevik> (raw)
In-Reply-To: <87o8c84j3f.fsf@suse.de>

Hi Richie,
...

> >>> > +#else
> >>> > +
> >>> > +int main(const attr_unused int argc, const attr_unused char *const *const argv)
> >>> > +{
> >>> > +	emit_error("clang-checks was not built correctly; libclang headers are not installed!\n");
> >>> emit_error() is not visible here, thus build fails. Please add it
> >>before HAVE_CLANG_C_INDEX_H.

> > +1

> > Uhg.


> >>> Or you could just use tst_test.h with TST_NO_DEFAULT_MAIN and here would be TST_TEST_TCONF()
> >>> (+ LTP_ATTRIBUTE_UNUSED).

> >> ...
> >>> > +/* Copied from lib/tst_ansi_color.c */
> >>> > +static int color_enabled(const int fd)

> >> Also you'd probably get tst_color_enabled() and other things from
> >> lib/tst_ansi_color.c for color handling for free when using
> >> tst_test.h.

> > We would probably have to build the ltplib with HOSTCC. I don't think we
> > can just include the headers.

> > It is tempting, but it also seems very circular. I can imagine someone
> > half refactoring a library and wanting to run the checks on one
> > translation unit. However Make would detect a dependency has changed, so
> > would try to rebuild the checker with a broken ltplib...

> > We could probably make it work, but having the checker depend on the
> > thing it checks seems like a recipe for complication. Meanwhile we just
> > get to share a few macros and string constants.

> Although we could create a tools lib with shared code for the meta data
> parser and maybe the future parallel executor if that does not use the
> test lib.

Uh, I'm sorry, I missed build dependency. It's probably not worth to rewriting
this part just to reuse a bit of code. We might look into that in the future,
but for now please just fix a build with your original approach.

Kind regards,
Petr

      reply	other threads:[~2021-06-15 10:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 11:56 [LTP] [RFC PATCH v3 0/2] Libclang based analyzer Richard Palethorpe
2021-06-14 11:56 ` [LTP] [RFC PATCH v3 1/2] Add 'make check' and clang-check to build system Richard Palethorpe
2021-06-15 14:16   ` Cyril Hrubis
2021-06-14 11:56 ` [LTP] [RFC PATCH v3 2/2] Start libclang based analyzer and TEST() check Richard Palethorpe
2021-06-14 13:41   ` Petr Vorel
2021-06-14 13:52     ` Petr Vorel
2021-06-14 14:25       ` Richard Palethorpe
2021-06-14 14:27         ` Richard Palethorpe
2021-06-15 10:44           ` Petr Vorel [this message]

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=YMiEfQfujl9lJ1lZ@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    /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