[libvirt PATCH 342/351] meson: add syntax-check

Pavel Hrdina phrdina at redhat.com
Tue Jul 28 14:04:39 UTC 2020


On Tue, Jul 28, 2020 at 03:48:29PM +0200, Peter Krempa wrote:
> On Thu, Jul 16, 2020 at 11:59:38 +0200, Pavel Hrdina wrote:
> > Signed-off-by: Pavel Hrdina <phrdina at redhat.com>
> > ---
> >  build-aux/Makefile.in                         |  9 +++
> >  .../Makefile.nonreentrant                     |  0
> >  build-aux/meson.build                         | 30 +++++++++
> >  build-aux/syntax-check.mk                     | 62 +++++++++----------
> >  meson.build                                   |  2 +
> >  5 files changed, 72 insertions(+), 31 deletions(-)
> >  create mode 100644 build-aux/Makefile.in
> >  rename Makefile.nonreentrant => build-aux/Makefile.nonreentrant (100%)
> >  create mode 100644 build-aux/meson.build
> 
> [...]
> 
> > +make_prog = find_program('make')
> > +
> > +# There is no way how to pass value to -j using run_target so let's use
> > +# it without any value to run all tests in parallel.
> > +run_target(
> > +  'syntax-check',
> > +  command: [
> > +    make_prog, '-C', meson.current_build_dir(), '-j', 'syntax-check',
> > +  ],
> 
> While I do run syntax check with unlimited '-j'. I don't think it's
> entirely cool to impose that on everybody. Specifically overcommiting
> the system is not cool. Since meson is automagically scaling can't we
> use the meson-detected cpu number here?

Unfortunately no, that was the first thing I was trying to figure out
by going through meson code as well. It's not ideal I know.

Other options are to not use -j at all which is no-go or we can add some
code to detect the available number of CPUs. But again it would not
reflect the fact if user runs 'ninja -j N'.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200728/be407247/attachment-0001.sig>


More information about the libvir-list mailing list