CMake + PIO Workflow explanation

1

I’m workin with PIO, CMake + CLion since years and I really like it.
I think my CMake knowledge is not the worst but recently I struggled with the following problem:
I tried to add one of my internal libs (logger) to a pio-Project.
I placed “logger” in a subfolder called .dependencies. (/.dependencies/logger)
In CMakeListsUser I tried everything I could think of to integrate logger.
e.g.:

set(LOGGER_PACKAGE "${CMAKE_CURRENT_LIST_DIR}/.dependencies/logger")

include_directories("${LOGGER_PACKAGE}")
FILE(GLOB_RECURSE EXTRA_LIB_SOURCES_LOGGER
    ${LOGGER_PACKAGE}/*.*
    )
set(EXTRA_LIB_SOURCES
    ${EXTRA_LIB_SOURCES}
    ${EXTRA_LIB_SOURCES_LOGGER}
)

Nothing worked. After two days back and forth I gave up and added

lib_extra_dirs =
    .dependencies

to my platformio.ini - This solved my problem but!!! in my opinion, what pio generates:

FILE(GLOB_RECURSE EXTRA_LIB_SOURCES
    ${CMAKE_CURRENT_LIST_DIR}/.pio/libdeps/esp32azd/*.*
    ${CMAKE_CURRENT_LIST_DIR}/.dependencies/*.*
)

Looks like my own attempt in CMakeListsUser.txt.

Can someone explain why the approach works in CMakeListsPrivate but doesn’t work in CMakeListsUser???

2

Hmmm - to answer my own question:
I think PIO doesn’t care how the whole CMake-Stuff looks like. I completely ignores it. CMakeLists* are only relevant for the IDE!
OMG - I always thought PIO generates it’s stuff based on cmake…

3

Oh no, no no. You don’t use CMake files to add a dependency. You need to tell PlatformIO about your dependency. The CMakeLists.txt that PlatformIO generates is a really fancy wrapper that just calls into pio run for compilation. PIO is always the build system. Otherwise it could not efficiently support all these IDEs – they are all made to call into PlatformIO for the actual compilation, so things only have to implemented once.

If you have a library, just add it to the lib/ folder of the project, or otherwise refer to it via lib_deps.