[Buildroot] [PATCH] package/python3: select host Python 3

[Buildroot] [PATCH] package/python3: select host Python 3

[Liam Hupfer]

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.

Select host Python 3 via Kconfig to expose why it is built, similar to
libffi.

Signed-off-by: Liam Hupfer <lhupfer@xes-inc.com>
---
 package/python3/Config.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/python3/Config.in b/package/python3/Config.in
index 38f0580aa4..cfc08bad86 100644
--- a/package/python3/Config.in
+++ b/package/python3/Config.in
@@ -11,6 +11,7 @@ config BR2_PACKAGE_PYTHON3
 	depends on !BR2_STATIC_LIBS
 	select BR2_PACKAGE_LIBFFI
 	select BR2_PACKAGE_BLUEZ5_UTILS_HEADERS if BR2_PACKAGE_BLUEZ5_UTILS
+	select BR2_PACKAGE_HOST_PYTHON3
 	help
 	  The python language interpreter.
 

base-commit: d571951c67d63824fcdf96cba8b59c80876a827a
-- 
2.46.0

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

Re: [Buildroot] [PATCH] package/python3: select host Python 3

[Arnout Vandecappelle via buildroot]

  Hi Liam,

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).

  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.

  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>
> ---
>   package/python3/Config.in | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/package/python3/Config.in b/package/python3/Config.in
> index 38f0580aa4..cfc08bad86 100644
> --- a/package/python3/Config.in
> +++ b/package/python3/Config.in
> @@ -11,6 +11,7 @@ config BR2_PACKAGE_PYTHON3
>   	depends on !BR2_STATIC_LIBS
>   	select BR2_PACKAGE_LIBFFI
>   	select BR2_PACKAGE_BLUEZ5_UTILS_HEADERS if BR2_PACKAGE_BLUEZ5_UTILS
> +	select BR2_PACKAGE_HOST_PYTHON3
>   	help
>   	  The python language interpreter.
>   
> 
> base-commit: d571951c67d63824fcdf96cba8b59c80876a827a

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

Re: [Buildroot] [PATCH] package/python3: select host Python 3

[Liam Hupfer]

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