GreenGiant wrote: ↑Wed Jun 24, 2020 10:19 am
So had to revisit this.
The stuff in the ADF doesn't allude to much, perhaps I am not seeing it?
If I use:
Does that overwrite what I previously set in the root of my project, or does it append to it?
If you put this line in the component CMakeLists.txt then it will probably be ignored.
I don't think there is a supported way to nest components, one of the first things the build does is to enumerate all the component directories for the project and use this information to build the graph of component dependencies, etc.
I can suggest three ways to solve this problem, from the simplest to the most complex:
1 (Simplest)
I know you said this is what you were trying to avoid, but for the layout shown in the first post then this is still by far the simplest method. Add the following line in the top-level project CMakeLists.txt file:
Code: Select all
set(EXTRA_COMPONENT_DIRS components/ components/component1)
The build system will find the components component1, component1a, component2.
I understand this breaks the principle of encapsulation (to make component1 responsible for everything it contains), but I wanted to mention it in case anyone else reads this post and wonders what the very simplest approach is.
Another equally simple method would be to register all of component1a's sources and directories inside component1's CMakeLists.txt file, but I assume this is also what you're trying to avoid.
2
It is possible to use CMake
nested directories inside a single component.
Here's an example in esp-idf master branch. We have a component esp_system, and the top-level CMakeLists.txt file includes a subdirectory named port:
https://github.com/espressif/esp-idf/bl ... eLists.txt
The "port" subdirectory has its own CMakeLists.txt file. Note that this is not an ESP-IDF component any more, so it's not possible to use idf_component_register() here. But it is possible to add source files and include directories to the top-level component using CMake commands (the component target name is available in the COMPONENT_LIB variable):
https://github.com/espressif/esp-idf/bl ... eLists.txt
The port/CMakeLists.txt file adds a deeper subdirectory, whose name depends on the target chip. So for esp32 it's this file:
https://github.com/espressif/esp-idf/bl ... eLists.txt
Note that even though there are 3 CMakeLists.txt files here, there is only one ESP-IDF "component" and one CMake library target. But all of the files in the 3 directories are encapsulated in the respective CMakeLists.txt files.
2 (Most Complex)
It's possible to do even more CMake wizardry, for example the ESP-IDF mbedTLS component uses add_subdirectory() to include the mbedTLS upstream CMakeLists.txt file (which has no ESP-IDF specific contents), and then manually adds those mbedTLS CMake library targets to the mbedTLS component:
https://github.com/espressif/esp-idf/bl ... ts.txt#L59
(This option requires some deep CMake spelunking so I'd recommend skipping it unless you're really sure it's what you need.)
...
Are any of those methods useful for you, or is it important that component1 and component1a are independent IDF components in the build system? If you can explain a bit more about your exact use case then we might be able to suggest another way to support it.
GreenGiant wrote: ↑Wed Jun 24, 2020 10:19 am
Also, the documentation uses
whereas the ADF uses
[...]
What's the difference, is one newer so we should be using that?
ESP-ADF is still based on ESP-IDF V3.3 and the "register_component()" function with the various variables was used in the
CMake support released in V3.x.
In ESP-IDF V4.0 we introduced idf_component_register() which is more "CMake like" and also more powerful. The "register_component()" syntax is still supported for backwards compatibility, but if your project only targets ESP-IDF V4.0 and newer then I would recommend using idf_component_register().