Object returned by executable() does not expand to full path when used as argument in test()

[keszybz]

http://mesonbuild.com/Reference-manual.html#build-target-object says

full_path() returns a full path pointing to the result target file. NOTE: In most cases using the object itself will do the same job as this and will also allow Meson to setup inter-target dependencies correctly. Please file a bug if that doesn't work for you.

... so I'm filling this.

        exe = executable('systemd-tmpfiles',
                         'src/tmpfiles/tmpfiles.c',
                         include_directories : includes,
                         link_with : [libshared],
                         dependencies : [libacl],
                         install_rpath : rootlibexecdir,
                         install : true,
                         install_dir : rootbindir)
        public_programs += [exe]

        test('test-systemd-tmpfiles',
             test_systemd_tmpfiles_py,
             args : exe)

this expands to

--- command ---
/home/zbyszek/src/systemd-work/src/test/test-systemd-tmpfiles.py systemd-tmpfiles

i.e. it runs the system-installed binary instead of the one I want to test.

Using exe.full_path() works fine, but it will break dependency calculation when #1704 is resolved.

[jpakkane]

The reason this happens is that we pass a relative path to the target. So if they are in a different directory then it expands to foo/bar.exe and correspondingly to bar.exe if they are in the same dir. Due to path expansion (and the fact that most people don't have . in their path) the latter will resolve to the system binary.

We try to avoid absolute paths when possible, since they have the tendency to break reproducible builds because paths get captured in the weirdest of ways. Maybe we should detect this case and then do ./bar.exe.

[nirbheek]

In this case exe is passed as an argument to the test and the absolute path would only be embedded in the meson test serialization data, so we should do it automatically. In fact, this was supposed to be fixed already, see: #1094

[keszybz]

FWIW, I still see the same behaviour (just the name, not an absolute path and not ./foo) with meson-0.53.2-1.git88e40c7.fc32.noarch.

[eli-schwartz]

This was re-reported in #5984 and fixed in commit cb6662b (meson 0.55.0)