[libvirt PATCH 008/351] meson: src/util/virfile: rewrite virFileActivateDirOverrideForProg
pkrempa at redhat.com
Wed Jul 22 08:39:25 UTC 2020
On Wed, Jul 22, 2020 at 10:33:58 +0200, Ján Tomko wrote:
> On a Wednesday in 2020, Peter Krempa wrote:
> > On Thu, Jul 16, 2020 at 11:54:04 +0200, Pavel Hrdina wrote:
> > > With meson we no longer have .libs directory with the actual binary so
> > > we have to take a different approach to detect if running from build
> > > directory.
> > >
> > > This is not as robust as for autotools because if you select --prefix
> > > in the build directory it will incorrectly enable the override as well
> > > but nobody should do that.
> > This wouldn't be that much of a problem as it would end up pointing to
> > the same files.
> > More of a problem is if we falsely assume that the override is not
> > necessary.
> That's why I'd rather drop this "override-by-binary-path" approach
> and use the env variable in the "run" script for this.
That would mandate using ./run even in situations where it was not
Similarly to what libtool did with the shell script overlay file, meson
links the binaries with local versions of the .so's compiled by the
project. This means that the binary can still be run without using
./run. (It's relinked on install I presume).
Thus I'd prefer if we still keep the possibility to exec binaries
without invoking ./run, but the overrides for dynamicaly loaded files
will still work.
More information about the libvir-list