From: Patrick Steinhardt <ps@pks.im>
To: Peter Seiderer <ps.report@gmx.net>
Cc: git@vger.kernel.org, Eli Schwartz <eschwartz@gentoo.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] meson: distinguish build and target host binaries
Date: Tue, 4 Mar 2025 10:07:48 +0100 [thread overview]
Message-ID: <Z8bC5LINEPmoarRy@pks.im> (raw)
In-Reply-To: <20250303150956.24a1815e@gmx.net>
On Mon, Mar 03, 2025 at 03:09:56PM +0100, Peter Seiderer wrote:
> > this patch addresses the issue reported at [1], where it is impossible
> > to specify the shell, Python and Perl paths during cross-compilation
> > when using Meson.
>
> I still believe that is is a 'misuse' of the cross-file (as stated already
> here [1]) the given programs in cross-file are to be meant to run while
> cross-compiling (at compile time) and not on the target (e.g. it would be
> impossible to find a program (as the name find_program indicates) at
> compile/configure where the target layout is yet unknown....
>
> I believe the correct solution is an extra configure option for cross-compile
> and a sane default (or find_program) in case of native build...
I'm mostly going by Eli's assessment [1]:
On Tue, Feb 18, 2025 at 09:41:23AM -0500, Eli Schwartz wrote:
> Overriding it via the cross file would be fine -- if your goal is to
> only ever find_program(..., native: false) in order to detect a path and
> embed it, then it doesn't matter whether cross files are for running
> cross tools on the build machine or for looking up cross tools to detect
> a path and embed it, since the two goals would never *come into
> conflict*. And that's what actually matters -- if you are concerned that
> cross files will be wrong as they specify the cross-compile environment
> not the install environment, then you shouldn't be using find_program()
> either, you should be exclusively using build options.
So this makes me assume that this usage is okay.
The reason why I prefer using a cross-file is that it makes it possible
to specify the complete environment for a cross-compilation in a single
file. This would include both the toolchain, but also target-specific
options like the shell/Python/Perl path. In theory, this would make it
possible to eventually start shipping machine files as part of the Git
project that are completely sufficient to set up cross-compilation for
e.g. Windows.
That being said, this is only my opinion and it's not set into stone. I
just don't quite see the cross-file as abuse and think it has merit to
do it that way. If there is another good argument why having a build
option is preferable then I'm all ears and happy to revise my opinion.
Patrick
[1]: 24df8aa2-760f-4da3-88b0-ab97796373fd@gentoo.org
prev parent reply other threads:[~2025-03-04 9:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-03 12:10 [PATCH] meson: distinguish build and target host binaries Patrick Steinhardt
2025-03-03 14:09 ` Peter Seiderer
2025-03-04 9:07 ` Patrick Steinhardt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8bC5LINEPmoarRy@pks.im \
--to=ps@pks.im \
--cc=eschwartz@gentoo.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ps.report@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).