From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/6] boot/uboot: support building U-Boot with Python 3.x
Date: Sun, 3 May 2020 15:12:15 +0200 [thread overview]
Message-ID: <20200503151215.5d39140e@windsurf.home> (raw)
In-Reply-To: <20200503080231.GV15673@scaer>
Hello Yann,
On Sun, 3 May 2020 10:02:31 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > +if BR2_TARGET_UBOOT_NEEDS_PYTHON
> > +
> > +choice
> > + prompt "Python version"
> > + default BR2_TARGET_UBOOT_NEEDS_PYTHON2
> > +
> > +config BR2_TARGET_UBOOT_NEEDS_PYTHON2
> > + bool "python 2.x"
> > + help
> > + Select this option if U-Boot needs a host Python 2.x
> > + interpreter. This is the case for some U-Boot
> > + configurations, prior to U-Boot 2020.01.
> > +
> > +config BR2_TARGET_UBOOT_NEEDS_PYTHON3
> > + bool "python 3.x"
> > + help
> > + Select this option if U-Boot needs a host Python 3.x
> > + interpreter. This is the case for some U-Boot
> > + configurations, after U-Boot 2020.01.
> > +
> > +endchoice
>
> I don't like it much that construct, where a boolean hides a choice.
> Instead, we can siumply use a choice (options names abbreviated as I'm
> lazy to type them full):
>
> choice
> "Python support needed"
>
> config UBOOT_PY_NONE
> "none"
>
> config UBOOT_PY2
> "python2"
>
> config UBOOT_PY3
> "python3"
>
> endchoice
>
> > +endif
> > +
> > config BR2_TARGET_UBOOT_NEEDS_PYLIBFDT
> > bool "U-Boot needs pylibfdt"
> > + select BR2_TARGET_UBOOT_NEEDS_PYTHON
> > help
> > Select this option if your U-Boot board configuration
> > requires the Python libfdt library to be available.
> >
> > config BR2_TARGET_UBOOT_NEEDS_PYELFTOOLS
> > bool "U-Boot needs pyelftools"
> > + select BR2_TARGET_UBOOT_NEEDS_PYTHON
>
> Of course here (both pylibfdt and pyelftools), you'd have to switch to a
> depends-on, but that does not change much afterall.
If I use depends on like you suggest, we break backward compatibility.
Indeed, an existing configuration with
BR2_TARGET_UBOOT_NEEDS_PYELFTOOLS=y or
BR2_TARGET_UBOOT_NEEDS_PYLIBFDT=y will not have UBOOT_PY2 enabled, and
therefore host-python will no longer be built.
My proposal was carefully designed to make sure existing configurations
do not break.
A possible solution would be something like the below, but I believe it
might cause some circular dependency:
choice
prompt "Python support needed"
default UBOOT_PY2 if BR2_TARGET_UBOOT_NEEDS_PYLIBFDT
default UBOOT_PY2 if BR2_TARGET_UBOOT_NEEDS_PYELFTOOLS
config UBOOT_PY_NONE
...
config UBOOT_PY2
...
config UBOOT_PY3
...
endchoice
config BR2_TARGET_UBOOT_NEEDS_PYLIBFDT
bool "U-Boot needs pylibfdt"
depends on !UBOOT_PY_NONE
config BR2_TARGET_UBOOT_NEEDS_PYELFTOOLS
bool "U-Boot needs pyelftools"
depends on !UBOOT_PY_NONE
Of course, if you don't care about backward compatibility, then your
proposal works. Let me know how you want to proceed.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2020-05-03 13:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-02 21:28 [Buildroot] [PATCH 0/6] Support Python 3.x in U-Boot Thomas Petazzoni
2020-05-02 21:28 ` [Buildroot] [PATCH 1/6] package/python3-pyelftools: new package Thomas Petazzoni
2020-05-02 21:28 ` [Buildroot] [PATCH 2/6] boot/uboot: support building U-Boot with Python 3.x Thomas Petazzoni
2020-05-03 8:02 ` Yann E. MORIN
2020-05-03 13:12 ` Thomas Petazzoni [this message]
2020-05-09 21:45 ` Yann E. MORIN
2020-05-02 21:28 ` [Buildroot] [PATCH 3/6] configs/olimex_a20_olinuxino_lime{, 2}: use " Thomas Petazzoni
2020-05-02 21:28 ` [Buildroot] [PATCH 4/6] configs/beelink_gs1: " Thomas Petazzoni
2020-05-02 21:58 ` Clément Péron
2020-05-02 21:28 ` [Buildroot] [PATCH 5/6] configs/roc_pc_rk3399: fix U-Boot dependencies Thomas Petazzoni
2020-05-02 21:28 ` [Buildroot] [PATCH 6/6] configs/nanopi_neo4: " Thomas Petazzoni
2020-05-15 21:05 ` [Buildroot] [PATCH 0/6] Support Python 3.x in U-Boot Yann E. MORIN
2020-05-17 17:43 ` Clément Péron
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=20200503151215.5d39140e@windsurf.home \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.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