fd6829f645
Las dos ramas habian divergido: master llevaba el modo lenguaje ESP-IDF puro (#139) y v3.2 la ruta de compilacion IDF v5.5 para toda la familia ESP32 mas los arreglos de venv/toolchain. Ambas tocaban espidf_compiler.py. Los dos lados son ejes ORTOGONALES y se conservan enteros: - use_idf5 / arduino_mode (v3.2): que arbol IDF usa el build (5.5 vs 4.4) y si cabe Arduino-como-componente. - pure_idf (master): el modo LENGUAJE que elige el usuario; sus ficheros son las fuentes del componente main con su propio app_main(). Resolucion: - _build_env acepta los tres. Un build IDF puro fuerza arduino_mode a falso: la plantilla CMake mete el componente arduino-esp32 en cuanto existe ARDUINO_ESP32_PATH, asi que dejarlo puesto compilaba el core de Arduino en un build que no tiene sketch. Lo cazaron los tests de master. - VELXIO_PURE_SKETCH solo con pure_idf, nunca con arduino_mode a falso a secas: un target sin core arduino-esp32 sigue entregando un SKETCH al traductor legacy y no debe tomar la rama del glob puro. - La identidad del build-dir suma los dos tokens (|idf:N|ard:N y |lang:pure): ningun par de esas combinaciones puede compartir un build/ configurado. - La cadena de escritura de fuentes queda pure_idf -> arduino_mode -> legacy. - sdkconfig: render de v3.2 (con target/use_idf5) mas el filtrado de simbolos CONFIG_ARDUINO* de master cuando el build es puro. test/backend/unit/test_espidf_compiler.py: los 7 tests que ya estaban rotos en v3.2 (AttributeError: idf5_path, fixture sin actualizar desde que se anadio la seleccion de IDF) vuelven a pasar. Verificado: backend 293 pasan / 0 fallan (v3.2 traia 7 rotos); frontend 2268 pasan / 0 fallan en los dos shards. |
||
|---|---|---|
| .. | ||
| api | ||
| core | ||
| database | ||
| mcp | ||
| models | ||
| schemas | ||
| services | ||
| utils | ||
| __init__.py | ||
| main.py | ||