[vlc-devel] [vlc-commits] configure.ac: Use AC_PATH_PROGS for luac

[Rémi Denis-Courmont]

Le 2016-08-03 15:43, Hugo Beauzée-Luyssen a écrit :
>>> This is a wrong assumption when it comes to PATH
>>
>> You don't get to decide if it's right or wrong. automake is designed
>> that way, and unless we patch it or use something else, then we have 
>> to
>> abide by the assumption it makes.
>>
>>> containing our
>>> contrib generated binaries. My understanding of autoconf is that 
>>> PATH
>>> isn't part of the output variables, leaving us with no choice but
>>> using an absolute path.
>>
>> By that flawed logic there would be no AC_CHECK_PROGS ever, and 
>> every
>> executable variable would convey an absolute path. Indeed, you'd get 
>> the
>> exact same problem with any other AC_CHECK_PROGS or wrapper around
>> AC_CHECK_PROGS that configure.ac uses.
>>
>
> I fail to understand your reasoning. AC_CHECK_PROGS is enough if the
> binary is meant to be part of the path, and AC_PATH_PROGS is meant 
> for
> other cases, since you can't change the PATH from configure.

AC_PATH_PROGS is meant for cases where an absolute path is required. 
That is notably:
- when PATH is not looked up at all (e.g. execl(), execv()),
- when the executable file itself is the matter, for another purpose 
than executing it,
- when (outside of the build process) PATH is expected to differ.

As an example, generating a script or an executable that calls another 
executable at run-time might require AC_PATH_PROGS. But not build tools, 
as already outlined (twice).

Furthermore, the contrib output directories contains cross-compiled 
binaries. So its bin and sbin directory really have no business in the 
PATH of the VLC build process anyway. I had not noticed, but this is 
clearly a pre-existing bug in the configure script.

For missing build tools, on the one hand, you should use extras/tools, 
not contribs. On the other hand, it seems extras/tools has the exact 
same bug coded into configure.

> I have no problem reverting this patch, but I'd like to have an 
> alternative solution which doesn't involve installing luac system wide 
> before compiling.

Well, I respect your choice to make your life miserable by not using a 
decent OS to build from. But that's not an excuse for kludging the build 
system.

Besides extras/tools is supposed to solve that problem.

-- 
Rémi Denis-Courmont
http://www.remlab.net/