Иногда при сборке проекта возникает длительная пауза, если система сборки по какой-то причине не может прверить/обновить актуальные зависимостей проекта:

$ idf.py build
Executing action: all (aliases: build)
Running ninja in directory /home/user/myproject/build
Executing "ninja all"...
[0/1] Re-running CMake...
-- Building ESP-IDF components for target esp32c3
... здесь возникает долгая пауза ...
NOTICE: Cannot establish a connection to the component registry. Skipping checks of dependency changes.
NOTICE: Processing 2 dependencies:
NOTICE: [1/2] jschwefel/esp-idf-ds3231 (1.0.3)
NOTICE: [2/2] idf (5.4.1)
... далее сборка проходит как обычно.

Так просходит потому, что система сборки (idf.py build system) для проектов ESP-IDF автоматически проверяет зависимости компонента (component dependencies), используя IDF Component Manager [1] (ваше приложение также считается компонентом). Когда скрипт idf.py конфигурирует проект (например при запуске команд idf.py build или idf.py reconfigure), он выполняет несколько действий, относящихся к зависимостям:

• Обрабатывает манифесты idf_component.yml: считывается информация о зависимостях, определенная в файле idf_component.yml внутри каталогов компонетов вашего проекта.

• Создается файл dependencies.lock (см. вопрос Q32 FAQ [2]): он генерируется в корневом каталоге проекта, и в нем содержится подробный список всех разрешенных зависимостей.

• Требуемые зависимости загружаются в директорию managed_components.

Важно отметить, что IDF Component Manager предназначен для предотвращения избыточной работы. После того, как файл dependencies.lock существует и зависимости загружены, Диспетчер компонентов не будет пытаться восстановить или повторно загрузить зависимости, если сами файлы idf_component.yml или dependencies.lock не изменятся. Это означает, что в типичных сценариях построения шаги проверки зависимостей и загрузки эффективно "пропускаются", если зависимости уже существуют и обновлены.

Таким образом, не существует специального аркумента комндной строки наподобие idf.py skip check dependencies, потому что система неявно обрабатыват эту оптимизацию. Если вы столкнулись с проблемой проверки зависимостей, то возможные причины: поврежден тулчейн, проблемы переменных окружения, либо необходимо выполнить очистку и пересборку проекта, чтобы произошло свежее разрешение зависимостей.

[Как удалить зависимость от компонента, сохранив его функционал]

Утилита idf.py в ESP-IDF не имеет специальной команды наподобие remove-dependencies для управления зависимостями, перечисленными в idf_component.yml. 

Однако вы можете эффективно "удалить" обслуживаемые зависимости, выполнив следующие шаги:

1. Сделайте копию кода компонентов, для которых вы хотели бы сохранить функционал и удалить при этом от них зависимость. Удалите из папки managed_components директорию компонента (компонентов), зависимость от которых вы хотели бы удалить.

2. Отредактируйте в редакторе текста файл idf_component.yml вашего компонента (компонента приложения main или определеного компонента, где была декларирована зависимость). Найдите запись компонента, зависимость от которого вы хотите удалить, и удалите эту запись.

3. Перенесите исходный код компонента, зависимость от которого вы удалили, в тело приложения.

4. Выполните полную очистку, удалив папку build (или выполните команду idf.py fullclean).

5. Выполните сборку проекта, как обычно, командой idf.py build, устраните все ошибки, связанные с переносом исходного кода компонента.

Следует иметь в виду, что когда вы удаляете таким способом зависимость, вы теряете возможность автоматического обновления функционала этого компонента, если его автор нашел и исправил какие-то ошибки. Как как полностью удалить зависимости, см. Q34 FAQ [2].

[Ссылки]

1. ESP-IDF Component Manager.
2. ESP-IDF FAQ.