Re: Meson build leaks host 'sh' path to target build when cross-compiled

> On Mon, Feb 10, 2025 at 12:26:03PM +0100, Peter Seiderer wrote:
>> On Mon, 10 Feb 2025 08:41:18 +0100, Patrick Steinhardt <ps@pks.im> wrote:
>>> On Sun, Feb 09, 2025 at 01:30:27PM +0100, Peter Seiderer wrote:
>>> [snip]
>>>>   The meson build tries to execute the non-existent '/usr/bin/sh' (instead of
>>>>   '/bin/sh' as the autoconf build), 'which sh' on the host returns
>>>>   '/usr/bin/sh'...
>>>>
>>>>   From meson.build
>>>>
>>>>    [...]
>>>>    186 shell = find_program('sh', dirs: program_path)
>>>>    [...]
>>>>    685   '-DSHELL_PATH="' + fs.as_posix(shell.full_path()) + '"',
>>>>
>>>>   Do not use the result of 'find_program('sh',...)' for '-DSHELL_PATH='
>>>>   (at least not for cross-compile), use fix '/bin/sh' instead or make it
>>>>   configurable via a meson option?
>>>
>>> Hm, very true. We're mixing up concerns here by treating the build
>>> environment and the target environment the same.
>>>
>>> I guess the proper fix is to wire up the "native:" parameter when we
>>> call `find_program()`, which allows us to tell Meson whether it should
>>> find an executable for the build or the target host. And then, for those
>>> binaries where we actually need to know about both the build and target
>>> host's locations, we'd end up calling `find_program()` twice.
>>>
>>> For executables that are supposed to be used on the target host Meson
>>> would then know to first consult the cross file, which could look like
>>> this:
>>>
>>>     [binaries]
>>>     sh = '/target/path/to/sh'
>>>     perl = '/target/path/to/perl'
>>>
>>> Meson would then pick up that file via `meson setup --cross-file
>>> <CROSSFILE_PATH> <BUILDDIR>`.
>>
>> Sorry, I believe this will not work..., the description of the native
>> parameter in find_program ([2]) on the first sight sounds like doing the
>> right thing, but as far as I read the 'Cross compilation' page ([3], [4]) the
>> tools under the '[binaries]' section are the tools used while cross-compiling
>> (running on the build machine) and not the paths/tools on the target
>> (or as meson nomenclature host/target)...
> 
> Quoting the documentation of `find_program()`'s `native` parameter [1]:
> 
>     Defines how this executable should be searched. By default it is set to
>     false, which causes Meson to first look for the executable in the cross
>     file (when cross building) and if it is not defined there, then from the
>     system. If set to true, the cross file is ignored and the program is
>     only searched from the system.
> 
> So I think this should work as expected when passing the file via
> `--cross-file`, shouldn't it? If we are cross-compiling we'd find the
> target binaries via the cross file when `native: false`, which is
> exactly what we want.
> 
> But I see what you're saying. The _intent_ is to specify the environment
> of the cross-compiling environment, and not to describe the target
> environment.
> 
> I can think of two alternatives:
> 
>   - We can introduce build options for this. If unset, we continue to
>     use the result of `find_program()`. Otherwise, we use the value
>     specified by the user.
> 
>   - We can introduce properties into the cross file that allow the user
>     to specify those parameters. We can then retrieve them by calling
>     `meson.get_external_property()`, but only when cross-compiling.
> 
> Let me also Cc Eli, he might have an opinion on how to do this.