Declare framework-internal dependencies in the framework #110

New issue

Open

opened 2025-01-02 04:35:59 -06:00 by gilles-peskine-arm · 0 comments

gilles-peskine-arm commented

2025-01-02 04:35:59 -06:00

(Migrated from github.com)

The test data generators all follow the pattern that framework/scripts/generate_xxx_tests.py --list prints the list of output files (and there's --list-for-cmake to produce the same list in a CMake-friendly format). We should expand that, or add another option, to list the dependencies.

The dependencies can include:

Data files (presumably from framework/data_files) referenced in the script.
Python modules from framework/scripts/mbedtls_framework — maybe we can find those automatically using Python introspection?
Source code (e.g. crypto_config.h) read by the script.

An example of where this would have been useful is https://github.com/Mbed-TLS/mbedtls-framework/pull/83, which required an awkward dance to keep the build scripts working:

In the framework, create a Python module psa_test_case.py.
In consuming branches, add psa_test_case.py as a dependency when running generate_psa_tests.py.
In the framework, start using psa_test_case.py in generate_psa_tests.py.
Update consuming branches with the updated generate_psa_tests.py.

The back-and-forth due to steps 1 and 2 complicate the history of framework updates, which is a pain in itself in the best of cases. We wouldn't need steps 1 and 2 if the framework was the authority for its own dependencies.

The build scripts in Mbed TLS and TF-PSA-Crypto call several scripts from the framework, and need to know the dependencies of those scripts (data files and auxiliary Python modules). Currently, those dependencies are recorded in `**/Makefile` and `**/CMakeLists.txt` in the consuming repositories. Since the dependencies result from code in the framework, we should declare them in the framework repository. The test data generators all follow the pattern that `framework/scripts/generate_xxx_tests.py --list` prints the list of output files (and there's `--list-for-cmake` to produce the same list in a CMake-friendly format). We should expand that, or add another option, to list the dependencies. The dependencies can include: * Data files (presumably from `framework/data_files`) referenced in the script. * Python modules from `framework/scripts/mbedtls_framework` — maybe we can find those automatically using Python introspection? * Source code (e.g. `crypto_config.h`) read by the script. An example of where this would have been useful is https://github.com/Mbed-TLS/mbedtls-framework/pull/83, which required an awkward dance to keep the build scripts working: 1. In the framework, create a Python module `psa_test_case.py`. 2. In consuming branches, add `psa_test_case.py` as a dependency when running `generate_psa_tests.py`. 3. In the framework, start using `psa_test_case.py` in `generate_psa_tests.py`. 4. Update consuming branches with the updated `generate_psa_tests.py`. The back-and-forth due to steps 1 and 2 complicate the history of framework updates, which is a pain in itself in the best of cases. We wouldn't need steps 1 and 2 if the framework was the authority for its own dependencies.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/mbedtls-framework#110

No description provided.

Rows
Columns