ESP32 Forum

I have noticed that, in spite of the clear guidelines provided in "build-system.rst" regarding the relationship between components and their include files, that a number of directories in "esp-idf/components/" do not follow the guideline.

Some of these situations, like libcoap, makes sense in order to maintain the original structure. Others, such as "components/driver" and "components/freertos" does not make sense to me.

"components/drivers/include" does not include any includes, but only has a subdir, again called "driver" that includes the actual header files.

Similarly "components/freertos/include" does not contain the normal/expected FreeRTOS includes, but only has a single subdir being another "freertos" below it, this including the normal FreeRTOS as well as xtensa RTOS related includes.

The impact of the FreeRTOS inconsistency is that all common (to other hardware platforms) type modules that need to include FreeRTOS.h, task.h etc. does not find the includes expected at "components/freertos/include".

Any specific reason I might be missing ?

Andre

Scoping of FreeRTOS includes under freertos/ directory has been kept in line with ESP8266 and ESP31B SDKs. In my opinion, the fact that FreeRTOS puts files with common names such as 'task.h' and 'queue.h' into the include path is a bad decision prone to cause name collisions.

For drivers, reasoning was exactly the same: names such as 'uart.h' and 'i2c.h' are fairly generic and it's better not to pollute the top-level include path with them.

If you need to use original freertos paths in a project which targets multiple platforms, you may add necessary paths via CFLAGS variable in your project or component makefiles.