forked from mirrors/qmk_firmware
7e27d72cbc
There was an import cycle in the Python modules: - `qmk.build_targets` imported `qmk.cli.generate.compilation_database`; - importing `qmk.cli.generate.compilation_database` requires initializing `qmk.cli` first; - the initialization of `qmk.cli` imported the modules for all CLI commands; - `qmk.cli.compile` imported `qmk.build_targets`. This cycle did not matter in most cases, because `qmk.cli` was imported first, and in that case importing `qmk.cli.generate.compilation_database` did not trigger the initialization of `qmk.cli` again. However, there was one corner case when `qmk.bulld_targets` was getting imported first: - The `qmk find` command uses the `multiprocessing` module. - The `multiprocessing` module uses the `spawn` start method on macOS and Windows. - When the `spawn` method is used, the child processes initialize without any Python modules loaded, and the required modules are loaded on demand by the `pickle` module when receiving the serialized objects from the main process. The result was that the `qmk find` command did not work properly on macOS (and probably Windows too); it reported exceptions like this: ImportError: cannot import name 'KeyboardKeymapBuildTarget' from partially initialized module 'qmk.build_targets' (most likely due to a circular import) Moving the offending `qmk.cli.generate.compilation_database` import into the method which actually uses it fixes the problem. |
||
---|---|---|
.. | ||
cli | ||
tests | ||
__init__.py | ||
build_targets.py | ||
c_parse.py | ||
commands.py | ||
comment_remover.py | ||
constants.py | ||
converter.py | ||
datetime.py | ||
decorators.py | ||
errors.py | ||
flashers.py | ||
git.py | ||
importers.py | ||
info.py | ||
json_encoders.py | ||
json_schema.py | ||
keyboard.py | ||
keycodes.py | ||
keymap.py | ||
makefile.py | ||
math.py | ||
painter.py | ||
painter_qff.py | ||
painter_qgf.py | ||
path.py | ||
search.py | ||
submodules.py | ||
util.py |