How to specify path to a shared mbed-os in mbed CLI2?

Mbed CLI
1

After creating a project without downloading a copy of Mbed OS:

mbed-tools new -c test01

the configuration command

mbed-tools configure -m LPC1768 -t GCC_ARM --mbed-os-path /home/zoli/src/mbed/sys/6.16.0/mbed-os

worked fine.

But then the command

mbed-tools compile -m LPC1768 -t GCC_ARM --mbed-os-path /home/zoli/src/mbed/sys/6.16.0/mbed-os

failed with the following message:

CMake Error at CMakeLists.txt:10 (include):
  include could not find requested file:

    /home/zoli/src/mbed/app/os-6/CMake/test01/mbed-os/tools/cmake/app.cmake


CMake Error at CMakeLists.txt:14 (add_subdirectory):
  add_subdirectory given source
  "/home/zoli/src/mbed/app/os-6/CMake/test01/mbed-os" which is not an
  existing directory.


CMake Error at CMakeLists.txt:22 (mbed_set_post_build):
  Unknown CMake command "mbed_set_post_build".


-- Configuring incomplete, errors occurred!
See also "/home/zoli/src/mbed/app/os-6/CMake/test01/cmake_build/LPC1768/develop/GCC_ARM/CMakeFiles/CMakeOutput.log".
ERROR: CMake invocation failed!

More information may be available by using the command line option '-v'.
2

you need to set the MBED_PATH in CMakeLists.txt.

This is what I used with a structure like

--- app --- prog1
      |    |
      |     -- prog2
      |
     mbed-os

cmake_minimum_required(VERSION 3.19.0)

set(MBED_PATH ../../mbed-os CACHE INTERNAL "")
set(MBED_CONFIG_PATH ${CMAKE_CURRENT_BINARY_DIR} CACHE INTERNAL "")
set(APP_TARGET blinky-F411)

include(${MBED_PATH}/tools/cmake/app.cmake)
3

Thank you for the tip. I solved it by adding a symbolic link to the shared mbed-os directory.
However, It’s disappointing and annoying to realize that the

mbed-tools compile --mbed-os-path <PATH>

command does not work!

I think I stick to CLI1.

4

When you use it by your own, then it works. But symbolic links are unusual in a windows environment.
Setting the mbed-os to a relative path works, it has to be done only in CMakeLists and the compile command.
CLI1 is no fun with large projects or when you add something like lvgl oder other libs that contain also example code. Then you need a lot of mbedignore entries.

Another solution is to use the mbed-ce fork. This allows also in a simple way to create projects for different targets and multiple apps with one mbed-os source. The compile time is also reduced and the integration in VSC works very well.

5

You are right. Sorry, I forgot to mention that I’m on Linux (Ubuntu 22.04.1 LTS) and I used symbolic link just as a workaround because the essential command

mbed-tools compile -m <target> -t <toolchain> --mbed-os-path <PATH>

does not wok on Linux! Neither with absolute nor with relative path!

To be honest with you, I haven’t had any problems with CLI1 so far. For me it’s an easy to use and reliable tool. No issues with adding libraries and I don’t have to manually edit “symple” CMakeLists.txt files. When there are examples included I just pack them to a zip file so no .mbedignore’s are needed.

But everybody has different taste. And fortunately we have a choice to select what we like more. :slightly_smiling_face:

The mbed-ce seems very promising. I know that VSC is a very popular IDE but I prefer the Qt Creator. I use it for all my projects (PC, Raspberry Pi, Mbed, Arduino), except the Android one. So when a CLI2 QtCreator generator is available I’ll be pleased to try it.

6

no problem, that is the nice thing with Mbed, there are many ways to build your target.

I’m using git now a lot, and I want to have all libraries imported as git projects or submodules. For 3rd party libs, it is important not to modify these locally. Then you can update to newer version by one click (git pull). Some bigger libs like lvgl have also cmake configurations, that can be used in Mbed also.

And yes, learning cmake is more difficult than CLI1, it takes some time and is maybe not easy to understand.