Compatibility between "normal CMake" and ESP-IDF

[permal]

That's correct. Do you think a subproject would be more appropriate here?

Just a hunch, but wasn't it made like it is now to prevent cluttering IDEs integrating with CMake with tens of targets of no interest to the app-developer?

The current build system (with IDF as a library) is working fine, except that the output binary has to be written to the same folder as the top-level CMakeFiles.txt so that esp.py can find it. Only other thing left from my view is fixing the tool chain so that xtensa-gcc can build the CMake test projects which will enable full IDE integration (in both gcc5 and gcc8 ofc).

[Oleg Endo]

I think the components/libraries should be all individual cmake projects, not just sub-targets of the main app project.

Sometimes there are situations where one has to use different (and potentially conflicting compiler flags) for libraries, like some libraries requiring a certain optimization levels/options or language standard settings (with GNU extension, without ...). In such cases the resulting libraries would still be ABI compatible and can be used together in the final executable. That's when build settings should be kept separately in each project scope.

No idea what an IDE would do -- I'm not using one.
However, right now in my case there are > 100 make targets, which are the IDF component library targets as well as other libraries which are included as cmake projects. So I guess it won't make a big difference from this point of view.

[Oleg Endo]

BTW, when in error or in doubt ... the cmake compiler tests can be knocked out.. by adding the following to the toolchain file (just as an example):

Code: Select all

set (CMAKE_C_COMPILER_ID "GNU")
set (CMAKE_C_COMPILER_VERSION "7.3.1")
set (CMAKE_C_COMPILER_FORCED TRUE)

set (CMAKE_CXX_COMPILER_ID "GNU")
set (CMAKE_CXX_COMPILER_VERSION "7.3.1")
set (CMAKE_CXX_COMPILER_FORCED TRUE)

set (CMAKE_ASM_COMPILER_ID "GNU")
set (CMAKE_ASM_COMPILER_VERSION "7.3.1")

[permal]

BTW, when in error or in doubt ... the cmake compiler tests can be knocked out.. by adding the following to the toolchain file (just as an example):

Code: Select all

set (CMAKE_C_COMPILER_ID "GNU")
set (CMAKE_C_COMPILER_VERSION "7.3.1")
set (CMAKE_C_COMPILER_FORCED TRUE)

set (CMAKE_CXX_COMPILER_ID "GNU")
set (CMAKE_CXX_COMPILER_VERSION "7.3.1")
set (CMAKE_CXX_COMPILER_FORCED TRUE)

set (CMAKE_ASM_COMPILER_ID "GNU")
set (CMAKE_ASM_COMPILER_VERSION "7.3.1")

Oh, that's interesting. I'll try that tonight and see if it takes us closer to a working integration.

[permal]

Oh, that's interesting. I'll try that tonight and see if it takes us closer to a working integration.

Nope, can't get that to work. CLion seems disregard the tool chain file during test.

[ESP_Angus]

Oh, that's interesting. I'll try that tonight and see if it takes us closer to a working integration.

Nope, can't get that to work. CLion seems disregard the tool chain file during test.

Are you passing the CLion the toolchain file as part of the project properties in the IDE?

[permal]

Are you passing the CLion the toolchain file as part of the project properties in the IDE?

Yes.

[chodzikman]

Hi permal,

I have successfully built your g3 project and I am trying to adjust mine project layout and cmakes according to your, however I get this odd behavior:

Code: Select all

[mchodzikiewicz@raczek:build|feature/bsp]$ cmake -DCMAKE_TOOLCHAIN_FILE=/home/mchodzikiewicz/CLionProjects/beerbob_fw_esp32/openbrewery_bsp_esp32/esp-idf/tools/cmake/toolchain-esp32.cmake ../
-- The C compiler identification is GNU 5.2.0
-- The CXX compiler identification is GNU 5.2.0
-- Check for working C compiler: /usr/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /usr/bin/xtensa-esp32-elf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/xtensa-esp32-elf-g++
-- Check for working CXX compiler: /usr/bin/xtensa-esp32-elf-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at main/CMakeLists.txt:6 (project):
  The CMAKE_C_COMPILER:

    xtensa-esp32-elf-gcc

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.


CMake Error at main/CMakeLists.txt:6 (project):
  The CMAKE_CXX_COMPILER:

    xtensa-esp32-elf-g++

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!
See also "/home/mchodzikiewicz/CLionProjects/beerbob_fw_esp32/build/CMakeFiles/CMakeOutput.log".
See also "/home/mchodzikiewicz/CLionProjects/beerbob_fw_esp32/build/CMakeFiles/CMakeError.log".

Have you encountered this problem?

Here is commit that behaves like that:
https://gitlab.com/OpenBrewery/Firmware ... b9bc5c85c7

Also: it behaves just the same with CLion and without providing external toolchain file, moreover - whole xtensa toolchain IS in my PATH

[permal]

Hi permal,

I have successfully built your g3 project and I am trying to adjust mine project layout and cmakes according to your, however I get this odd behavior:

Code: Select all

[mchodzikiewicz@raczek:build|feature/bsp]$ cmake -DCMAKE_TOOLCHAIN_FILE=/home/mchodzikiewicz/CLionProjects/beerbob_fw_esp32/openbrewery_bsp_esp32/esp-idf/tools/cmake/toolchain-esp32.cmake ../
-- The C compiler identification is GNU 5.2.0
-- The CXX compiler identification is GNU 5.2.0
-- Check for working C compiler: /usr/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /usr/bin/xtensa-esp32-elf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/xtensa-esp32-elf-g++
-- Check for working CXX compiler: /usr/bin/xtensa-esp32-elf-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at main/CMakeLists.txt:6 (project):
  The CMAKE_C_COMPILER:

    xtensa-esp32-elf-gcc

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.


CMake Error at main/CMakeLists.txt:6 (project):
  The CMAKE_CXX_COMPILER:

    xtensa-esp32-elf-g++

  is not a full path and was not found in the PATH.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!
See also "/home/mchodzikiewicz/CLionProjects/beerbob_fw_esp32/build/CMakeFiles/CMakeOutput.log".
See also "/home/mchodzikiewicz/CLionProjects/beerbob_fw_esp32/build/CMakeFiles/CMakeError.log".

Have you encountered this problem?

Here is commit that behaves like that:
https://gitlab.com/OpenBrewery/Firmware ... b9bc5c85c7

Also: it behaves just the same with CLion and without providing external toolchain file, moreover - whole xtensa toolchain IS in my PATH

From within CLion?! If yes, how?

You've already pointed to what I would consider to be the error i in this case - the path.

[chodzikman]

I share the same feeling, but as I said - it is in my system PATH (also - your s3 project compiles successfully on my machine), therefore I feel something fishy going on under the esp-idf cmake hood (that somehow gets rid of my PATH)...

I just thought that you might encountered the same problem so I asked. I'll double check the differences between projects this evening