[libvirt PATCH 008/351] meson: src/util/virfile: rewrite virFileActivateDirOverrideForProg

[Ján Tomko]

On a Wednesday in 2020, Peter Krempa wrote:
>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
>required before.
>

Yes, that's what I meant.

Jano

>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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200722/8705af79/attachment-0001.sig>