micropython / micropython-lib

Core Python libraries ported to MicroPython
Other
2.39k stars 994 forks source link

os-path causes build conflict with unix_ffi os #795

Open osresearch opened 8 months ago

osresearch commented 8 months ago

Building fails for the unix port when adding the glob package to the variant manifest with:

require("glob", unix_ffi=True)

glob's manifest requires os-path, without unix_ffi, and that in turns requires os also without unix_ffi:

require("os", unix_ffi=True)
require("os-path")

os-path's manifest requires os:

require("os")
package("os")

This causes a conflict with the os that has already been required with unix_ffi:

build-standard/frozen_content.c:20526:27: error: redefinition of ‘const_qstr_table_data_os___init__’
20526 | static const qstr_short_t const_qstr_table_data_os___init__[158] = {
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
build-standard/frozen_content.c:17919:27: note: previous definition of ‘const_qstr_table_data_os___init__’ was here
17919 | static const qstr_short_t const_qstr_table_data_os___init__[158] = {
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
....

If I add unix_ffi=True to lib/micropython-lib/python-stdlib/os-path/manifest.py, then it is able to compile the frozen content.

dpgeorge commented 7 months ago

If I add unix_ffi=True to lib/micropython-lib/python-stdlib/os-path/manifest.py, then it is able to compile the frozen content.

I don't think that's the correct solution because it will most likely break targets (eg bare-metal ports) that can't use the unix-ffi code.

One solution would be to make it ignore subsequent packages if one is already require'd by the same name. So in this case the unix_ffi os will take precedence because it's require'd first.

dpgeorge commented 7 months ago

Should be fixed by https://github.com/micropython/micropython/pull/13620