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@xxxxxx> 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.
> > diff --git a/templates/meson.build b/templates/meson.build
> > index 1faf9a44ce..986c2e03be 100644
> > --- a/templates/meson.build
> > +++ b/templates/meson.build
> > @@ -1,6 +1,6 @@
> > template_config = configuration_data()
> > -template_config.set('PERL_PATH', perl.found() ? fs.as_posix(perl.full_path()) : '')
> > -template_config.set('SHELL_PATH', fs.as_posix(shell.full_path()))
> > +template_config.set('PERL_PATH', perl.found() ? fs.as_posix(target_perl.full_path()) : '')
>
> Above should read (perl.found() vs. target_perl.found()):
>
> +template_config.set('PERL_PATH', target_perl.found() ? fs.as_posix(target_perl.full_path()) : '')
Ah, yes, indeed.
Patrick
[1]: https://mesonbuild.com/Reference-manual_functions.html#find_program
