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
prev parent 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