[Buildroot] [PATCH v2 1/1] package/micropython: make use of recent micropython-lib

Yann E. MORIN yann.morin.1998 at free.fr
Mon Jan 29 18:49:48 UTC 2024


Abilio, All,

Thanks for this new iteration!

On 2024-01-28 18:29 -0800, Abilio Marques spake thusly:
> Until now, micropython-lib was a package that installed v1.9.3,
> which is more than 6 years old. This was acceptable since micropython
> never made any other official release of the library until v1.20.
> 
> Meanwhile, the libraries underwent a reorganization, and they are now
> available in a directory structure that cannot be copied directly into
> the target. This is my theory on why v1.9.3 is still present in the

We try to avoid singular first-person messages in the commit log, and
prefer the more neutral plural first-person "we", or the passive tense.
Here, I'd rephrase it as;

    This might explain why v1.9.3 is still...

> current day buildroot (which comes with micropython v1.22).
> 
> This commit introduces an auxiliary script to collect those libraries
> and reorder them into a structure that can then be copied into
> /usr/lib/micropython. The script utilizes a module from the tools
> directory of the micropython repo.
> 
> As part of the changes made by the micropython project, the libraries
> are now released together with the interpreter. They are cloned as a
> submodule into the lib/micropython-lib directory.
> 
> These are the 2 main reasons why the old buildroot micropython-lib
> package is being removed.
> 
> With this commit, micropython-lib is installed (optionally) as part
> of micropython. The original config variable name was retained as it
> fits with the micropython package 'namespace", and thus this is
> backward compatible and no legacy handling is needed.
> 
> I tried to keep it simple. It makes use of existing micropython tools
> (used to process manifests) to discover the list of packages available
> in micropython-lib. My hope is that by relying on them, any future
> changes in directory structure will be covered by the official
> "manifestfile.py" tool.

Ditto, no "I" or "my". No need to resend just ofe of the phrasing, it
can be fixed when applying.

One thing that again got me down the host-micropython rabbit-hole, is
that we don't need host-micropython at all, because the manifestfile
module is actual CPython code, not micropython code, so we really, like
really-really, want to write that script for CPython.

[--SNIP--]
> diff --git a/package/micropython/micropython.mk b/package/micropython/micropython.mk
> index 37c148da94..5a0c5616a5 100644
> --- a/package/micropython/micropython.mk
> +++ b/package/micropython/micropython.mk
> @@ -57,4 +57,21 @@ define MICROPYTHON_INSTALL_TARGET_CMDS
>  		install
>  endef
>  
> +ifeq ($(BR2_PACKAGE_MICROPYTHON_LIB),y)
> +define MICROPYTHON_COLLECT_LIBS
> +	$(EXTRA_ENV) PYTHONPATH=$(@D)/tools:/$PYTHONPATH \

There is no need to complement PYTHON path with $PYTHONPATH. Indeed,
PYTHONPATH only *augments* the search path, it does not replace the
standard path, so we should just need:

    $(EXTRA_ENV) PYTHONPATH=$(@D)/tools \
    package/micropython/collect_micropython_lib.py \
        $(@D) $(@D)/.built_pylib

No need to resend, I'll tinker with it tonight.

Thanks!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'



More information about the buildroot mailing list