Hello Junio, On Mon, 10 Feb 2025 08:18:44 -0800, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > > 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. > > ... > > The patch should look somewhat like the attached patch, but it conflicts > > with my in-flight patch series at [1]. I'll wait for that series to be > > merged to `next` before sending out the fix. > > Interesting. When we did our make-based build, we never seriously > considered cross building into a platform where the path to the > basic tools differed between the host and target hosts. At least in > our build procedure in olden times, I think we used to assume that > what we just built can be run inside the build procedure on the host > platform even outside the tests, which would make cross building > impossible. > > Now, since we are "fixing" this aspect of the build for meson-based > build, should we also make the same fix for make-based build as well? > > I'd have to say that I prefer to see it done out of pure principle > (i.e. we earlier declared that meson is not yet replacing make, so > adding new shinies only to meson-world is like making the make-world > bitrot as if we do not care). > > But on the other hand, nobody complained that they cannot cross > build with make-based build seriously enough to cause us consider > doing something about it for the past 20 years, so the pragmast in > me tells me that it is not worth it doing it in make-based build. Maybe all doing (autoconf) cross builds where happy with the defaults from the Makefile (SHELL_PATH = /bin/sh, PERL_PATH = /usr/bin/perl) on host and target (as the buildroot autoconf package since 2013) and only users doing native builds fiddled around with non-default values? Regards, Peter > > > Thanks for your report! > > Yup, thanks.