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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.