Set CMAKE_SYSROOT variable

[robamu]

I have not seen this directive anywhere as part of the toolchain file. Documentation can be found here . I still want to check/test some more things, so marked WIP

[atsju]

Nothing wrong with WIP. I converted PR to draft. Please just convert to normal PR when you are done.

[robamu]

The resulting passed --sysroot compiler flag will be --sysroot=/usr/arm-none-eabi .. I'm not 100 % sure whether this is correct, I actually expected the full path, basically something similar to

--sysroot=<USER>/.local/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/11.2.1-1.1.1/.content/arm-none-eabi

for my cross-compiler..

UPDATE: I simply forgot to set STM32_TOOLCHAIN_PATH. Path looks good now

[Hish15]

Hi @robamu, From your last UPDATE I understand that this is not needed? I read the documentation of --sysroot for GCC, and it looks like we don't need it in our case. We don't need it because we don't rely on external files, and provide all the paths in the corresponding cmake targets.

[robamu]

I think this still has valid application because it specifies paths CMake will use when using find_ functions. For example, my use case would be to install a library like etl or fmt into the cross compiler sysroot and then use find_package to find the installed package. I still need to test whether this works properly, I only verified that everything compiles and runs as usual.

[Hish15]

@robamu Aren't specific path for cmake find's user related ? I think this is why cmake documentation says to put it in a toolchain file only.

This variable may only be set in a toolchain file specified by the [CMAKE_TOOLCHAIN_FILE](https://cmake.org/cmake/help/latest/variable/CMAKE_TOOLCHAIN_FILE.html#variable:CMAKE_TOOLCHAIN_FILE) variable.

find_package has already default paths, where are you planing to install fmt or etl?

I'm not saying it does not make sense, just trying to understand the limitations with the by default behavior.

o/

[atsju]

Please note --sysroot is already passed manually to compiler https://github.com/ObKo/stm32-cmake/blob/1dcb772e93d4e1ffd0229516e16d276eb880c3b6/cmake/stm32/utilities.cmake#L20 and linker https://github.com/ObKo/stm32-cmake/blob/1dcb772e93d4e1ffd0229516e16d276eb880c3b6/cmake/stm32/utilities.cmake#L27 I suppose the proposal makes sense. Not for the find_ command but to automate these lines (which need to be updated). The fact that find_ will search there is only a side effect for me and I do not recommend to put the libraries into GCC installation. This is a hack OK for some quick fix/test but doesn't seem to be the professional/scalable/clean way to do. Each library should be in it's own folder and the folder must be taught to cmake in a different way in a project specific way.

I still need to test whether this works properly, I only verified that everything compiles and runs as usual.

please remember many people are using the repo in different ways. linux VS windows (with command line or with vscode+cmaketools). It's better to test everything, and if not possible describe the tests done to minimise maintainers tests

[robamu]

All code in common.cmake is loaded inside stm32_gcc.cmake and therefore part of the toolchain file.

If there are some directives left where --sysroot is added manually, they could be removed as part of the PR.

I think installing packages into the cross-compiler sysroot/ compilation tooling is a valid way to provide a dependency without an application requiring a full copy of the dependency (git submodule or unzipped tar-ball managed dependency) or refetching it at a full rebuild (FetchContent managed dependency). I am new to this way of dependency management as well and I think it is not very common for bare metal development, but it is a common way for dependency management in newer programming languages and CMake provides ways and tools to do it for (embedded) C/C++ as well.

[robamu]

About your comment with the tests:

Do you have a manual test procedure which you usually do on top of the tests executed by the CI/CD?

[atsju]

There is some CI/CD but not to test if VScode on windows, cmdline, linux, ... works. This type of change would not be seen by CI for example

[robamu]

I tried installing etl which was unproblematic because the library is header-only. It was found and then can be used without any issues. fmt is a bit more tricky because it is a compiled library. Using FetchContent or a git submodule to compile fmt as part of the project makes more sense here. It is still possible to install fmt, but then a custom toolchain file is used because some important compiler flags will be missing unless a target is linked against the specific target machine target. It still might sense to install it as part of some SDK for a specific board. In any case, setting CMAKE_SYSROOT appears to do the correct thing without breaking anything.

Test procedure for etl:

1. Install etl into the cross-compiler sysroot like the following, making sure that STM32_TOOLCHAIN_PATH is set in the environment accordingly

   git clone https://github.com/ETLCPP/etl
   cd etl
   git checkout 20.28.0
   mkdir build && cd build
   cmake -DCMAKE_INSTALL_PREFIX="$STM32_TOOLCHAIN_PATH/arm-none-eabi" ..
   sudo cmake --install .
   

2. Compile the test project found here

   git clone https://github.com/robamu-org/stm32-cmake-projects
   cd projects/etl
   mkdir build && cd build
   cmake -DBUILD_H743ZI=ON ..
   cmake --build . -j
   

I will try to perform the second part of this process in VS Code

[robamu]

The test repository already had some sample VS Code files. Those seem to work fine

[Hish15]

@atsju, I see no reason not to not merge this. As seen in #311, what we have now is not OK.

[Logiase]

This PR fix #311, and have tested under linux.