Two new tests are added.
1) test_check_python_dependencies
The test prepares artificial constraints file containing packages from
requirements.core.txt, which are also reported in pip-freeze output
for virtual env. The constraints file requires package versions higher
than currently installed in venv, so check_python_dependencies
should fail for all of them.
2) test_check_required_packages_only
Test for espressif/esp-idf/-/merge_requests/17917. After installing
core requirements, install additional foopackage, which is embedded.
Add version requirement for foopackage, which cannot be satisfied,
to constraints file. Since foopackage is not a direct requirement,
check-python-dependencies should not fail.
This also fixes existing TestCustomPythonPathInstall test, which sets
IDF_PYTHON_ENV_PATH, but does not restore it. Unittest seems to be
running tests in order based on class/test name. Meaning this test runs
before TestPythonInstall and all tests in TestPythonInstall are using
the latest tmpdir from TestCustomPythonPathInstall as IDF_PYTHON_ENV_PATH.
IOW TestPythonInstall is actually testing custom python env path, same as
TestCustomPythonPathInstall. This fixes it by restoring the
IDF_PYTHON_ENV_PATH. Note that since the actual IDF_PYTHON_ENV_PATH
was different(tmpdir) from PYTHON_DIR, the default PYTHON_DIR was never used,
so the tests were running with old python env(no
shutil.rmtree(PYTHON_DIR).
Since TestCustomPythonPathInstall is inheriting from TestPythonInstall
it also runs test_opt_argument and test_no_constraints for the second
time. This seems unnecessary, so this patch also skips these two tests
in TestCustomPythonPathInstall.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
IDF_PYTHON_ENV_PATH is the path where the Python environment is created
and used. By default it is inside IDF_TOOLS_PATH. IDF_PYTHON_ENV_PATH
was exported by idf_tools.py but was not imported back. This fixes the
issue and ESP-IDF will honor the value of IDF_PYTHON_ENV_PATH.
Closes https://github.com/espressif/esp-idf/issues/10489
This adds a new outdated option, which only lists outdated
packages installed in IDF_TOOLS_PATH. It searches for the
latest installed tool version in the IDF_TOOLS_PATH/tools path and
compares it against the latest available version in the tools.json
file. If the latest version of a tool installed in IDF_TOOLS_PATH/tools
is smaller, it's reported as outdated. Nothing is reported if the tool
is up to date.
Two new tests are added. First just checks if nothing is reported in
case there is no update available. The second artificially generates
new tools.json file called tools.outdated.json and sets XTENSA_ESP32_ELF
version to 'zzzzzz'. It then checks if the XTENSA_ESP32_ELF tool
is reported as outdated by the 'zzzzzz' version.
Description of the new outdated option is addedd to docs as well.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
On the build runners, the installation frequently takes around 150
seconds, which is above the current timeout. This change increases
the timeout.
Closes IDFCI-1436
'idf_tools.py add-version' has new options:
--override Override tool versions with new data
--checksum-file URL or path to local file with checksum/size for artifacts
Usage e.g.:
CHECKSUM_URL=https://github.com/espressif/crosstool-NG/releases/download/esp-2021r2/crosstool-NG-esp-2021r2-checksum.sha256
idf_tools.py add-version --tool xtensa-esp32-elf --version esp-2021r2 --override --checksum-file $CHECKSUM_URL
Positional argument 'files' moved to optional argument '--artifact-file'
Add tests for add-version logic
GDB now is standalone tool separated from toolchain due to frequent updates.
Added installation tests for the new tool.
Tests are changed because they were wrong, see explanation:
esp32 objdump:
40084290 <esp_crosscore_int_send_yield>:
......
/builds/espressif/esp-idf/components/esp_system/crosscore_int.c:145
4008429c: 000090 retw
With previous GDB backtrace was:
#0 0x4008429c in esp_crosscore_int_send_yield (core_id=0) at /builds/espressif/esp-idf/components/esp_system/crosscore_int.c:144
This commit fixes the backtrace with the right line number:
#0 0x4008429c in esp_crosscore_int_send_yield (core_id=0) at /builds/espressif/esp-idf/components/esp_system/crosscore_int.c:145
Other tests changes have the same cause of fixing.
Closes https://github.com/espressif/esp-idf/issues/6334
* fix failing tests: expect s2 binutils to be installed on s3,
expect risc-v toolchain to be installed on s2 and s3.
* improve readability by adding assert_tool_installed and
assert_tool_not_installed functions, instead of using an optional
assertIn argument
* rename "RISC" to "RISCV_ELF" as ULP is arguably very much "R" as in
"RISC"!
Allow user to select specific ESP_TARGET while setting up ESD_IDF.
Only necessary tools for given target will be downloaded and installed.
Closes https://github.com/espressif/esp-idf/issues/5113
Adds ESP32-C3 support
Updates ESP32-S3 overlay
GDB 9.2 for ESP32-C3 with core dump support
Linker supports eh-frame-hdr for ESP32-C3
Newlib 3.3.0 includes fixes for <cmath> funcs, for overflow when TZ calculating, for malloc checks
Binutils 2.35.1
Closes https://github.com/espressif/esp-idf/issues/6795
Fixup more for PSRAM issue;
Allow GDB work correctly with Privileged Registers;
Based on GCC 8.4.0;
Update a fix of C++ exception crashs from the GCC mainline;
Fixup strptime_l() and some locale in libc;
Closes https://github.com/espressif/esp-idf/issues/5765
Roland Dobai