[Buildroot] [PATCH] package/python3: add tk as core module

[Buildroot] [PATCH] package/python3: add tk as core module

[J. Langholz]

---
 package/python3/Config.in  | 6 ++++++
 package/python3/python3.mk | 9 +++++++--
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/package/python3/Config.in b/package/python3/Config.in
index 38f0580aa4..65afd4e6e2 100644
--- a/package/python3/Config.in
+++ b/package/python3/Config.in
@@ -108,6 +108,12 @@ config BR2_PACKAGE_PYTHON3_SQLITE
 	help
 	  SQLite database support
 
+config BR2_PACKAGE_PYTHON3_TK
+	bool "tk module"
+	select BR2_PACKAGE_TK
+	help
+	  tk (a.k.a. tkinter) module support
+
 config BR2_PACKAGE_PYTHON3_PYEXPAT
 	bool "xml module"
 	select BR2_PACKAGE_EXPAT
diff --git a/package/python3/python3.mk b/package/python3/python3.mk
index b9c5054a21..ca797f8cda 100644
--- a/package/python3/python3.mk
+++ b/package/python3/python3.mk
@@ -20,7 +20,6 @@ HOST_PYTHON3_CONF_OPTS += \
 	--without-ensurepip \
 	--without-cxx-main \
 	--disable-sqlite3 \
-	--disable-tk \
 	--with-expat=system \
 	--disable-curses \
 	--disable-codecs-cjk \
@@ -114,6 +113,13 @@ else
 PYTHON3_CONF_OPTS += --disable-openssl
 endif
 
+ifeq ($(BR2_PACKAGE_PYTHON3_TK),y)
+PYTHON3_DEPENDENCIES += tk
+PYTHON3_CONF_OPTS += --enable-tk
+else
+PYTHON3_CONF_OPTS += --disable-tk
+endif
+
 ifneq ($(BR2_PACKAGE_PYTHON3_CODECSCJK),y)
 PYTHON3_CONF_OPTS += --disable-codecs-cjk
 endif
@@ -184,7 +190,6 @@ PYTHON3_CONF_OPTS += \
 	--with-system-ffi \
 	--disable-pydoc \
 	--disable-test-modules \
-	--disable-tk \
 	--disable-nis \
 	--disable-idle3 \
 	--disable-pyc-build
-- 
2.34.1

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

Re: [Buildroot] [PATCH] package/python3: add tk as core module

[Thomas Petazzoni via buildroot]

Hello,

Thanks for your contribution. See below a comment.

On Wed, 20 Dec 2023 08:48:14 -0500
"J. Langholz" <jlangholzj@gmail.com> wrote:

> ---
>  package/python3/Config.in  | 6 ++++++
>  package/python3/python3.mk | 9 +++++++--
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/package/python3/Config.in b/package/python3/Config.in
> index 38f0580aa4..65afd4e6e2 100644
> --- a/package/python3/Config.in
> +++ b/package/python3/Config.in
> @@ -108,6 +108,12 @@ config BR2_PACKAGE_PYTHON3_SQLITE
>  	help
>  	  SQLite database support
>  
> +config BR2_PACKAGE_PYTHON3_TK
> +	bool "tk module"
> +	select BR2_PACKAGE_TK
> +	help
> +	  tk (a.k.a. tkinter) module support
> +
>  config BR2_PACKAGE_PYTHON3_PYEXPAT
>  	bool "xml module"
>  	select BR2_PACKAGE_EXPAT
> diff --git a/package/python3/python3.mk b/package/python3/python3.mk
> index b9c5054a21..ca797f8cda 100644
> --- a/package/python3/python3.mk
> +++ b/package/python3/python3.mk
> @@ -20,7 +20,6 @@ HOST_PYTHON3_CONF_OPTS += \
>  	--without-ensurepip \
>  	--without-cxx-main \
>  	--disable-sqlite3 \
> -	--disable-tk \

This is affecting the host package, but you're not adding host-tk to
the dependencies. Do we need a host python with TK support to be able
to build a target Python with TK support? (I don't think we do).

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/python3: add tk as core module

[John Langholz]

[-- Attachment #1.1: Type: text/plain, Size: 3245 bytes --]

Just to clarify to make sure I'm understanding the question: The concern is
that the host tk package (BR2_package_tk) isn't included as a dependency
(in my changes to host-python), is that correct?

Again, just for clarity; from my limited understanding, tk is included with
python but it's still just the interpreter for the tk/TCL packages. Because
of that, I was worried there was the potential to miss the other required
host packages and I was curious if there were some additional required
changes to ensure they were included. It appears that the "selected by"
statements for host-TCL and host-tk are handling this appropriately.

My one uncertainty is that they (host-tk and host-TCL) do both additionally
require the host-XORG package (BR2_package_XORG7) to be selected (via their
selected-by statement). I assumed that tk wouldn't ever be used without
some kind of window system and that's why the host-XORG package was
included in the selected-by statement for host-TCL and host-tk. That was my
only real unknown. That being said, In my limited testing it appears to
function as intended without the need for including host-tk as a dependency.

As an aside, I had some of this info included in the generated patch
cover-letter but I had not appropriately configured the cc-cover and
to-cover option for git email. As a result, when I ran the send-email
command it was left off! I'll fix that for the future to help give some
context.

On Wed, Dec 20, 2023 at 8:56 AM Thomas Petazzoni <
thomas.petazzoni@bootlin.com> wrote:

> Hello,
>
> Thanks for your contribution. See below a comment.
>
> On Wed, 20 Dec 2023 08:48:14 -0500
> "J. Langholz" <jlangholzj@gmail.com> wrote:
>
> > ---
> >  package/python3/Config.in  | 6 ++++++
> >  package/python3/python3.mk | 9 +++++++--
> >  2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/package/python3/Config.in b/package/python3/Config.in
> > index 38f0580aa4..65afd4e6e2 100644
> > --- a/package/python3/Config.in
> > +++ b/package/python3/Config.in
> > @@ -108,6 +108,12 @@ config BR2_PACKAGE_PYTHON3_SQLITE
> >       help
> >         SQLite database support
> >
> > +config BR2_PACKAGE_PYTHON3_TK
> > +     bool "tk module"
> > +     select BR2_PACKAGE_TK
> > +     help
> > +       tk (a.k.a. tkinter) module support
> > +
> >  config BR2_PACKAGE_PYTHON3_PYEXPAT
> >       bool "xml module"
> >       select BR2_PACKAGE_EXPAT
> > diff --git a/package/python3/python3.mk b/package/python3/python3.mk
> > index b9c5054a21..ca797f8cda 100644
> > --- a/package/python3/python3.mk
> > +++ b/package/python3/python3.mk
> > @@ -20,7 +20,6 @@ HOST_PYTHON3_CONF_OPTS += \
> >       --without-ensurepip \
> >       --without-cxx-main \
> >       --disable-sqlite3 \
> > -     --disable-tk \
>
> This is affecting the host package, but you're not adding host-tk to
> the dependencies. Do we need a host python with TK support to be able
> to build a target Python with TK support? (I don't think we do).
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com
>


-- 
Thanks,

-John Langholz

[-- Attachment #1.2: Type: text/html, Size: 4599 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

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

Re: [Buildroot] [PATCH] package/python3: add tk as core module

[Yann E. MORIN]

John, All,

I see that Thomas already sent a review, and you had further questions,
so let me try and address them here, as a review of your patch; it's
going to be basically the same comments as Thomas already provided, but
I'll try to expand on those.

Also, please do not top-post; instead, reply in-line

On 2023-12-20 08:48 -0500, J. Langholz spake thusly:
> ---

First, your commit needs a commit log; here it was empty. A commit log
explains what the situation is, why it needs to change, and how it is
changed. The "how" part is not a description of the patch; it is an
explanation. It can all be very brief in the most basic cases, but here
you may have to explain why the Tk module in python is important.

Then, your commit will have to be signed-off. The sign-off is described
in the manual:
    https://buildroot.org/downloads/manual/manual.html#submitting-patches

Quoting:

    Finally, the patch should be signed off. This is done by adding
    Signed-off-by: Your Real Name <your@email.address> at the end of the
    commit message. [...] See the Developer Certificate of Origin [0]
    for details.

    [0] http://developercertificate.org/

>  package/python3/Config.in  | 6 ++++++
>  package/python3/python3.mk | 9 +++++++--
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/package/python3/Config.in b/package/python3/Config.in
> index 38f0580aa4..65afd4e6e2 100644
> --- a/package/python3/Config.in
> +++ b/package/python3/Config.in
> @@ -108,6 +108,12 @@ config BR2_PACKAGE_PYTHON3_SQLITE
>  	help
>  	  SQLite database support
>  
> +config BR2_PACKAGE_PYTHON3_TK
> +	bool "tk module"
> +	select BR2_PACKAGE_TK
> +	help
> +	  tk (a.k.a. tkinter) module support

This new option is in the section dedicated to the python that will run
on the target. That is, it does not impact the python interpreter used
at build time.

Since you "select TK", you have to reproduce its dependencies. In this
case, all but one of the dependencies for TK are already dependencies
of Python3, and the probability python loses any of those dependencies
is extremely low, so we can just assume that will never happen, so we
don't need to expressly propagate them.

Except for the dependency on Xorg. That one you must propagate, because
Kconfig does not do it automatically. That then needs a little comment
to inform the user about the missing dependency.

So, ultimately, this new option may look something like:

    config BR2_PACKAGE_PYTHON3_TK
        bool "tk module"
        # All other tk dependencies already python dependencies
        depends on BR2_PACKAGE_XORG7 # tk
        select BR2_PACKAGE_TK
        help
          tk (a.k.a. tkinter) module support

    comment "Tk module needs Xorg"
        depends on !BR2_PACKAGE_XORG7

>  config BR2_PACKAGE_PYTHON3_PYEXPAT
>  	bool "xml module"
>  	select BR2_PACKAGE_EXPAT
> diff --git a/package/python3/python3.mk b/package/python3/python3.mk
> index b9c5054a21..ca797f8cda 100644
> --- a/package/python3/python3.mk
> +++ b/package/python3/python3.mk
> @@ -20,7 +20,6 @@ HOST_PYTHON3_CONF_OPTS += \
>  	--without-ensurepip \
>  	--without-cxx-main \
>  	--disable-sqlite3 \
> -	--disable-tk \

[1] This part of the change affects the python interpreter that is built
for the build machine, not the one that runs on the target, i.e. not the
one the option defined above applies to.

See later for a further discussion on that matter.

>  	--with-expat=system \
>  	--disable-curses \
>  	--disable-codecs-cjk \
> @@ -114,6 +113,13 @@ else
>  PYTHON3_CONF_OPTS += --disable-openssl
>  endif
>  
> +ifeq ($(BR2_PACKAGE_PYTHON3_TK),y)
> +PYTHON3_DEPENDENCIES += tk
> +PYTHON3_CONF_OPTS += --enable-tk
> +else
> +PYTHON3_CONF_OPTS += --disable-tk
> +endif

This change, and...

>  ifneq ($(BR2_PACKAGE_PYTHON3_CODECSCJK),y)
>  PYTHON3_CONF_OPTS += --disable-codecs-cjk
>  endif
> @@ -184,7 +190,6 @@ PYTHON3_CONF_OPTS += \
>  	--with-system-ffi \
>  	--disable-pydoc \
>  	--disable-test-modules \
> -	--disable-tk \

... this change, do apply to the target python, so they are correct.

So, if all you wanted was the Tk module on the target, what you did was
almost correct, except for the part [1], and for a non-empty commit log.
In this case, just fix those little nits, and respin a v2 of your patch.

Now, if you (also?) wanted the Tk module in the host python interpreter,
this is going to be a bit more involved. In this case, you'll hit a few
more issues.

First, we do not have ahost variant of Tk, so you would first need to
introduce it. We do have a variant of tcl, though, but you'll have to
see if it is fit (I noticed host-tcl has no dependency on host-zlib;
that's probably an oversight, and may also need to be fixed).

Then, Tk depends on xlib_libXft, so host-tk would probably also need to
depend on host-xlib_libXft, but we do not have a host variant of it, so
you'd need to introduce that as well. And that in turn, has a lot of
dependencies: fontconfig, freetype, xlib_libX11, xlib_libXext,
xlib_libXrender, and xorgproto, and you'd need you have a host variant
for each of them and so on, recursively...

Sine this is going to be a big stack of dependencies, we do not want to
enable it systematically, so we'd need an option to enable Tk, in a
similar manner as for the target variant, something like the following,
in package/python3/Config.in.host:

    config BR2_PACKAGE_HOST_PYTHON3_SSL
        bool "tk"
        help
          Tk module for host python3.

and in package/python3/python3.mk:

    ifeq ($(BR2_PACKAGE_HOST_PYTHON3_TK),y)
    HOST_PYTHON3_DEPENDENCIES += host-tk
    HOST_PYTHON3_CONF_OPTS += --enable-tk
    else
    HOST_PYTHON3_CONF_OPTS += --disable-tk
    endif

I am not sure what you explained in your other reply to Thomas, but if
the underlying explanation was "that will rely on the Tk library as
provided on the build machine distribution", then this is not going to
be OK, because we don't require that to be available. So, all the
dependencies will have to be available in Buildroot if you want to add
the Tk module in the host python interpreter.

And finally, if you need to have the Tk module in the host python
interpreter, you'll have to provide a commit log that explains the
use-case.

As Thomas noted: do we need the host python to have Tk support, so that
we can build the target python with tk support?

So, if you don't need the Tk module on the host python interpreter, then
do not add it just for the sake of adding it.

I hope that the above will answer your questions on Thomas' reply.

Do not hesitate to reply further if that was not clear enough.

In the meantime, I'll mark your patch as "changes requested" in
patchwork.

Regards,
Yann E. MORIN.

>  	--disable-nis \
>  	--disable-idle3 \
>  	--disable-pyc-build
> -- 
> 2.34.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/python3: add tk as core module

[John Langholz]

[-- Attachment #1.1: Type: text/plain, Size: 11152 bytes --]

Yann,

Thanks for the additional input, I've got some questions below. Overall, I
tried hitting the manual the best I could but obviously missed a few
things; I'm new to the git world and buildroot so I appreciate the patience
and extra clarification!

On Sun, Dec 31, 2023 at 12:28 PM Yann E. MORIN <yann.morin.1998@free.fr>
wrote:

> John, All,
>
> I see that Thomas already sent a review, and you had further questions,
> so let me try and address them here, as a review of your patch; it's
> going to be basically the same comments as Thomas already provided, but
> I'll try to expand on those.
>
> Also, please do not top-post; instead, reply in-line
>
> On 2023-12-20 08:48 -0500, J. Langholz spake thusly:
> > ---
>
> First, your commit needs a commit log; here it was empty. A commit log
> explains what the situation is, why it needs to change, and how it is
> changed. The "how" part is not a description of the patch; it is an
> explanation. It can all be very brief in the most basic cases, but here
> you may have to explain why the Tk module in python is important.
>
>
Then, your commit will have to be signed-off. The sign-off is described
> in the manual:
>     https://buildroot.org/downloads/manual/manual.html#submitting-patches
>
> Quoting:
>
>     Finally, the patch should be signed off. This is done by adding
>     Signed-off-by: Your Real Name <your@email.address> at the end of the
>     commit message. [...] See the Developer Certificate of Origin [0]
>     for details.
>
>     [0] http://developercertificate.org/
>
>
As mentioned, I had originally included the additional information per the
submitting patches part of the manual [1] in the cover-letter (that didn't
get sent). I see now that it's appropriate for each of the patches to have
that pertinent information in them before the "signed-off by section"
regardless of if a cover-letter is or isn't included. In addition to the
manual, I was referencing some other resources to set-up everything with
git, gitmail, etc. and I think there was just a misunderstanding of the
methodology on my end. For any future changes I'll make sure to include
that appropriately.

[1] https://buildroot.org/downloads/manual/manual.html#submitting-patches


> >  package/python3/Config.in  | 6 ++++++
> >  package/python3/python3.mk | 9 +++++++--
> >  2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/package/python3/Config.in b/package/python3/Config.in
> > index 38f0580aa4..65afd4e6e2 100644
> > --- a/package/python3/Config.in
> > +++ b/package/python3/Config.in
> > @@ -108,6 +108,12 @@ config BR2_PACKAGE_PYTHON3_SQLITE
> >       help
> >         SQLite database support
> >
> > +config BR2_PACKAGE_PYTHON3_TK
> > +     bool "tk module"
> > +     select BR2_PACKAGE_TK
> > +     help
> > +       tk (a.k.a. tkinter) module support
>
> This new option is in the section dedicated to the python that will run
> on the target. That is, it does not impact the python interpreter used
> at build time.
>
> Since you "select TK", you have to reproduce its dependencies. In this
> case, all but one of the dependencies for TK are already dependencies
> of Python3, and the probability python loses any of those dependencies
> is extremely low, so we can just assume that will never happen, so we
> don't need to expressly propagate them.
>
> Except for the dependency on Xorg. That one you must propagate, because
> Kconfig does not do it automatically. That then needs a little comment
> to inform the user about the missing dependency.
>
> So, ultimately, this new option may look something like:
>
>     config BR2_PACKAGE_PYTHON3_TK
>         bool "tk module"
>         # All other tk dependencies already python dependencies
>         depends on BR2_PACKAGE_XORG7 # tk
>         select BR2_PACKAGE_TK
>         help
>           tk (a.k.a. tkinter) module support
>
>     comment "Tk module needs Xorg"
>         depends on !BR2_PACKAGE_XORG7
>

In my initial reply to Thomas, this is what I was trying to convey. I had
done a few checks on the other dependencies (for tk) but the link to XORG
was one I was unsure about. I don't think tk would ever be used without a
graphical environment (due to its nature) but I agree/understand that
including the dependency makes it the most robust, so I'll include it.
Also, reading through the kconfig documentation [2] I see how the "comment"
line works as well. I had looked through a couple other config files but
wasn't sure on how to include it at the time but it makes sense now.

[2] https://kernel.org/doc/Documentation/kbuild/kconfig-language.txt


> >  config BR2_PACKAGE_PYTHON3_PYEXPAT
> >       bool "xml module"
> >       select BR2_PACKAGE_EXPAT
> > diff --git a/package/python3/python3.mk b/package/python3/python3.mk
> > index b9c5054a21..ca797f8cda 100644
> > --- a/package/python3/python3.mk
> > +++ b/package/python3/python3.mk
> > @@ -20,7 +20,6 @@ HOST_PYTHON3_CONF_OPTS += \
> >       --without-ensurepip \
> >       --without-cxx-main \
> >       --disable-sqlite3 \
> > -     --disable-tk \
>
> [1] This part of the change affects the python interpreter that is built
> for the build machine, not the one that runs on the target, i.e. not the
> one the option defined above applies to.
>
> See later for a further discussion on that matter.
>

Understood, based on the discussion below, I think this can be left as-is
before my changes then. See my response below.

>       --with-expat=system \
> >       --disable-curses \
> >       --disable-codecs-cjk \
> > @@ -114,6 +113,13 @@ else
> >  PYTHON3_CONF_OPTS += --disable-openssl
> >  endif
> >
> > +ifeq ($(BR2_PACKAGE_PYTHON3_TK),y)
> > +PYTHON3_DEPENDENCIES += tk
> > +PYTHON3_CONF_OPTS += --enable-tk
> > +else
> > +PYTHON3_CONF_OPTS += --disable-tk
> > +endif
>
> This change, and...
>
> >  ifneq ($(BR2_PACKAGE_PYTHON3_CODECSCJK),y)
> >  PYTHON3_CONF_OPTS += --disable-codecs-cjk
> >  endif
> > @@ -184,7 +190,6 @@ PYTHON3_CONF_OPTS += \
> >       --with-system-ffi \
> >       --disable-pydoc \
> >       --disable-test-modules \
> > -     --disable-tk \
>
> ... this change, do apply to the target python, so they are correct.
>
> So, if all you wanted was the Tk module on the target, what you did was
> almost correct, except for the part [1], and for a non-empty commit log.
>

Correct, the only intent was to include tk on the target. Reading through
this I understand a bit better what Thomas was initially asking. I didn't
fully realize what was going on with the mk file but looking at it now, I
see the comment above the HOST_PYTHON3_CONF_OPTS line and why the local
host needs python for cross-compiling. I'm not 100% sure, but I don't think
the tk module is needed for that purpose and at the very least, it was
functioning fine for other python needs before. Just to be sure I'll update
the changes and re-verify with an image on my end and test it to be sure
before submitting the updated patch.


> In this case, just fix those little nits, and respin a v2 of your patch.
>

With regards to v2 of the patch, I see section (25.5.5) of the manual has
some information on it. I've also made an account on patchwork and found
the original patch to get the messageID. Just to confirm, after I make the
above changes and generate v2 of the patch, the full command for mailing
out the v2 patch would be "$ git send-email --in-reply-to <message-id>"; is
that correct? Or does the "origin/master" option also need to be specified
for the v2 submittal (like what is shown at the end of section 22.5.2)?

Now, if you (also?) wanted the Tk module in the host python interpreter,
> this is going to be a bit more involved. In this case, you'll hit a few
> more issues.
>
> First, we do not have ahost variant of Tk, so you would first need to
> introduce it. We do have a variant of tcl, though, but you'll have to
> see if it is fit (I noticed host-tcl has no dependency on host-zlib;
> that's probably an oversight, and may also need to be fixed).
>
> Then, Tk depends on xlib_libXft, so host-tk would probably also need to
> depend on host-xlib_libXft, but we do not have a host variant of it, so
> you'd need to introduce that as well. And that in turn, has a lot of
> dependencies: fontconfig, freetype, xlib_libX11, xlib_libXext,
> xlib_libXrender, and xorgproto, and you'd need you have a host variant
> for each of them and so on, recursively...
>
> Sine this is going to be a big stack of dependencies, we do not want to
> enable it systematically, so we'd need an option to enable Tk, in a
> similar manner as for the target variant, something like the following,
> in package/python3/Config.in.host:
>
>     config BR2_PACKAGE_HOST_PYTHON3_SSL
>         bool "tk"
>         help
>           Tk module for host python3.
>
> and in package/python3/python3.mk:
>
>     ifeq ($(BR2_PACKAGE_HOST_PYTHON3_TK),y)
>     HOST_PYTHON3_DEPENDENCIES += host-tk
>     HOST_PYTHON3_CONF_OPTS += --enable-tk
>     else
>     HOST_PYTHON3_CONF_OPTS += --disable-tk
>     endif
>
> I am not sure what you explained in your other reply to Thomas, but if
> the underlying explanation was "that will rely on the Tk library as
> provided on the build machine distribution", then this is not going to
> be OK, because we don't require that to be available. So, all the
> dependencies will have to be available in Buildroot if you want to add
> the Tk module in the host python interpreter.
>
> And finally, if you need to have the Tk module in the host python
> interpreter, you'll have to provide a commit log that explains the
> use-case.
>
> As Thomas noted: do we need the host python to have Tk support, so that
> we can build the target python with tk support?
>
> So, if you don't need the Tk module on the host python interpreter, then
> do not add it just for the sake of adding it.
>
> I hope that the above will answer your questions on Thomas' reply.
>
> Do not hesitate to reply further if that was not clear enough.
>
> In the meantime, I'll mark your patch as "changes requested" in
> patchwork.
>
> Regards,
> Yann E. MORIN.
>
> >       --disable-nis \
> >       --disable-idle3 \
> >       --disable-pyc-build
> > --
> > 2.34.1
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot@buildroot.org
> > https://lists.buildroot.org/mailman/listinfo/buildroot
>
> --
>
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
> conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___
>      |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is
> no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v
>  conspiracy.  |
>
> '------------------------------^-------^------------------^--------------------'
>


-- 
Thanks,

-John Langholz

[-- Attachment #1.2: Type: text/html, Size: 14836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

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