Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Liam Hupfer <lhupfer@xes-inc.com>
To: Arnout Vandecappelle <arnout@mind.be>,
	"buildroot@buildroot.org" <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH] package/python3: select host Python 3
Date: Tue, 8 Jul 2025 22:10:14 +0000	[thread overview]
Message-ID: <rchbjpupc56.fsf@xes-inc.com> (raw)
In-Reply-To: <9b44f888-b884-4de8-9737-a16bf481d1c4@mind.be>

Hi Arnout, sorry for the delayed response.

Arnout Vandecappelle <arnout@mind.be> writes:

> On 15/11/2024 21:23, Liam Hupfer wrote:
>> Building Python for the target requires host Python via
>> PYTHON3_DEPENDENCIES. Host Python is exposed as a standalone Kconfig
>> option, so when BR2_PACKAGE_PYTHON3=y, it is possible for host Python to
>> be built even when BR2_PACKAGE_HOST_PYTHON3=n.
>
>   We have plenty of host packages where this is the case, and it’s not practical
> to do this correctly for all of them (cfr. e.g. BR2_PACKAGE_HOST_CMAKE which
> would need to be selected for all cmake packages).

IIRC this is the rationale Thomas P gave as well on IRC. From my naïve
perspective I don’t see why doing this for large, uncommon host packages
like Python means we must do this for all host packages. But I guess
host Python is not so uncommon anymore with the rise of Meson anyway.

To me it seems the Kconfig interface should expose all package
dependencies, rather than having some be implicit in the makefiles. I
wonder if it’s feasible to take the evaluated Make database and verify
that each package BAR in FOO_DEPENDENCIES has BAR_KCONFIG_VAR selected
by FOO_KCONFIG_VAR, or something like that, so that the makefiles
desynchronizing would cause a CI job to fail (or even makefile
evaluation, ideally). I’m not that familiar with the Buildroot internals
though so maybe that’s nonsensical.

>   However, in this particular case, there is a good reason to do the `select`:
> host-python3 has sub-options, which means that a package that requires one of
> those sub-optoins needs to add the select, which is also annoying.
>
>   Therefore, applied to master, thanks.

Works for me, thanks!

>   Regards,
>   Arnout
>
>>
>> Select host Python 3 via Kconfig to expose why it is built, similar to
>> libffi.
>>
>> Signed-off-by: Liam Hupfer <lhupfer@xes-inc.com>

—Liam
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      reply	other threads:[~2025-07-08 22:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-15 20:23 [Buildroot] [PATCH] package/python3: select host Python 3 Liam Hupfer
2025-02-03 11:37 ` Arnout Vandecappelle via buildroot
2025-07-08 22:10   ` Liam Hupfer [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=rchbjpupc56.fsf@xes-inc.com \
    --to=lhupfer@xes-inc.com \
    --cc=arnout@mind.be \
    --cc=buildroot@buildroot.org \
    /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