On Wed, Jul 22, 2020 at 11:43:09AM +0200, Peter Krempa wrote:
On Wed, Jul 22, 2020 at 11:32:07 +0200, Ján Tomko wrote:
> 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.
I strongly disagree with doing that. Meson tries hard to make the files
in the build directory work out of the box. This would make it partially
and magically fail in many cases which is imo very bad.
I agree with Peter here, since meson already does some magic to
correctly point to compiled libraries within the project it would be
nice to keep this functionality.
I'll try the sentinel file approach that Peter suggested to see if it
works and if it's not too ugly.
Thanks
Pavel