`meson install --tags` causes recompilation of unrelated targets

Describe the bug

Whenever I make a tiny change to meson.build trying to debug installation, I get 3 hundreds of irrelevant targets getting rebuilt. I presume it’s unneeded to say that this is annoying.

To make things worse, while recompiling these targets in such way it goes into some kind of silent mode where the progress is not shown until the very end of compilation.

To Reproduce

 λ ls
meson.build  myfile  test.c
 λ cat meson.build
project(
  'test',
  ['c'],
)

executable(
  'my_executable',
  ['test.c'],
  install: true,
)

install_data('myfile', install_dir: '/etc/', install_tag: 'mytag')
 λ ~/Projects/meson/meson.py build
The Meson build system
Version: 0.59.99
Source dir: /tmp/foo
Build dir: /tmp/foo/build
Build type: native build
Project name: test
Project version: undefined
C compiler for the host machine: ccache cc (gcc 11.1.0 "cc (GCC) 11.1.0")
C linker for the host machine: cc ld.bfd 2.36.1
Host machine cpu family: x86_64
Host machine cpu: x86_64
Build targets in project: 1

Found ninja-1.10.2 at /usr/bin/ninja
 λ cd build
 λ DESTDIR=/tmp/ ~/Projects/meson/meson.py install --tags my_tag
ninja: Entering directory `/tmp/foo/build'
[2/2] Linking target my_executable
Nothing to install.
 λ find -name test.c.o
./my_executable.p/test.c.o

Expected behavior

There should be no test.c.o file, because it was not marked with my_tag.

system parameters

• Is this a cross build or just a plain native build ? Native
• OS: Archlinux
• Python version: 3.9.6
• meson --version: current development version at commit 87e13af1c85c03
• ninja --version: 1.10.2

[eli-schwartz]

Hmm… Actually now that you said this, I realized it’s a bit more complicated. Your suggested commands produce the progress.

What actually happens is I have a meson target which creates a single package out of two dozens, which I call like ninja -C build services/foo-service.deb. Internally that target has to call meson install --tags my_tag.

Okay, that is an important detail. EXTREMELY important.

You are using ninja to invoke (meson to invoke) ninja. This may work, but it will not work nicely. Because ninja will buffer output for one target (in this case services/foo-service.deb) and only print the output after it does internal accounting and finishes the command (meson install in this case). Simply running meson install on the command line does not have this issue, because meson install runs ninja and faithfully reports the progress in real time.

There is a hack…

console (since 0.48.0): keyword argument conflicts with capture, and is meant for commands that are resource-intensive and take a long time to finish. With the Ninja backend, setting this will add this target to Ninja’s console pool, which has special properties such as not buffering stdout and serializing all targets in this pool.

Or, you could have this target depends: [list, of, all, targets, with, this, tag] and ninja will ensure only those targets are up to date, and run those targets before invoking meson install --tags my_tag. I would actually very much advise this, because then you could also pass --no-rebuild to meson install and it won’t try to rebuild targets you don’t need.

–no-rebuild is actually used internally by meson’s own ninja install alias for running meson install without arguments. Since it depends on “all” and thus knows that ninja already guarantees it is up to date. 😃

(Actually, ninja install uses the console pool too BTW.)

[eli-schwartz]

Note there is currently a proposal to add a method for getting the actual meson command which may not be in PATH or may be named something else like meson.py, which you may be interested in as well.