-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CMake integration #31193
Comments
(partially related to #8827 #36558)
set(CMAKE_SYSROOT ${SYSROOT_DIR}) But still we need to set openthread module does something like this target_include_directories(ot-config INTERFACE
$<TARGET_PROPERTY:zephyr_interface,INTERFACE_INCLUDE_DIRECTORIES>)
target_include_directories(ot-config SYSTEM INTERFACE
$<TARGET_PROPERTY:zephyr_interface,INTERFACE_SYSTEM_INCLUDE_DIRECTORIES>)
target_compile_definitions(ot-config INTERFACE
$<TARGET_PROPERTY:zephyr_interface,INTERFACE_COMPILE_DEFINITIONS>)
target_compile_options(ot-config INTERFACE
$<TARGET_PROPERTY:zephyr_interface,INTERFACE_COMPILE_OPTIONS> -fno-builtin) This allows us to build module code with Zephyr's compiler options. Unfortunately, |
I would like to contribute with reworking the CMake code, but firstly I would like to understand what is the rationale behind the current implementation. Could you answer those questions or point me to the documentation where I could find answers to those questions?
is necessary?
|
@tejlmand Could you support? |
Please find some explanation here:
This has to do with the old migration from KBuild as @SebastianBoe has described but also the way Zephyr handles the compilers. The Zephyr approach improves the speed significantly when building multiple samples with the same toolchain, so that building n-samples will only test the compiler 1 time.
There has been requests to support However, this should not prevent us from allow users with special wishes to specify CMAKE_TOOLCHAIN_FILE if they so like. Also I have often seen developers putting compile flags in their toolchain files that are not essential for the toolchain / compiler itself, biut because it's convenient, such as release build flags, debug flags, etc. The short description above is part of the reason that other features have had higher priority until now. |
Zephyr used CMAKE_TOOLCHAIN_FILE at some point. But the toolchain file must be specified each time on the command line, and to migrate to CMake we needed to be competitive with KBuild, which can be invoked as simply as "make". So we dropped support for it. I have no regrets about this decision. |
Since CMake 3.21 it can be specified as environment variable: Also with and thus avoiding to type it on each new CMake invocation.
me neither, but if someone finds it useful and valuable, as well as having the bandwidth to introduce it in a way that is compatible with existing Zephyr toolchain infrastructure, then I have no objections to such contribution. |
@KKoovalsky I just noticed your initial comment, so let me reply to some of your questions.
You should be able to find most commonly used flags that you require covered but as different compilers uses different flags for different compilers, there is a template for matching properties to flags, for example the template here: This ensures that you can enable a single Lines 110 to 111 in d5aa5c2
mapping to: zephyr/cmake/compiler/gcc/compiler_flags.cmake Lines 155 to 158 in d5aa5c2
or
depending on compiler in use and it's know capabilities (or tested capabilities if some versions of compiler might support a flag). But of course not everything is covered. If you want to do things purely in CMake and avoid Kconfig then you can take a look at the
This has been addressed here: |
I know you know this @tejlmand, but for others I would like to clarify that neither |
absolutely correct. But so far I still think the solution introduced with the KBuild re-write is superior as I describe in other comments. |
I'm struggling a little at an similar issue for an module. Applying yashi/module-sample works well, but AutoConf.cmake fails ins some case, e.g. adding "check_include_file(net/socket.h HAVE_NET_SOCKET_H)" doesn't work.
Adding:
results just in a different error:
In my case, it's only one header, so I fixed it. But it would be nice, if that works as well for modules. |
Hi @tejlmand, This issue, marked as an Enhancement, was opened a while ago and did not get any traction. Please confirm the issue is correctly assigned and re-assign it otherwise. Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason. @KKoovalsky you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you. Thanks! |
Hey! I guess after such time the initial problem may be fixed with a different approach, or by adapting to the zephyr's build system requirements. :) I haven't also used Zephyr for a while now, so I can't really give any input here. ;) Thanks for the support anyway! |
This would still be a nice to have regarding integration with Conan (see #31745) and probably other projects. I resorted to copy paste the compile flags used by Zephyr in a Conan profile where I could just have pointed to the toolchain file if it was there. Then I discovered that I understand where you're coming from, but when we recently started our new project, we thought "cool, Zephyr is CMake based, it'll be easy to integrate with our current code". Then I was disappointed to see it's yet another project working around CMake in its own unique, incompatibles ways. Reading the few issues around this here makes it clear there are actual reasons about this, and I understand that there's a lot of cmake code that would need to evolve, but it would be nice if there were some plan to move toward a more standard way of doing things. At least providing And then maybe by merging some features upstream? The global compiler flag cache is a nice thing and could maybe be useful to other projects. For the compiler features, maybe using Just my 2 cents here. All in all, it's working. I'm just sad that in 2024, it's still complicated to integrate two unrelated C++ projects even though they both use CMake. Best wishes for 2025 ;) |
Hello!
I wanted to start work with Zephyr as my main RTOS but unfortunately I abandon my efforts.
The main problem is that I have a current project whose build system is based on CMake and it works pretty well. I wanted to switch from another RTOS ecosystem to Zephyr since it's also built on top of CMake and its driver list is quite long.
The problem is that Zephyr doesn't work well with CMake. Let me list few problems which made me turn Zephyr down.
Order of the
find_package
andproject
calls is mandatory. Normallyfind_package(Zephyr)
must be called beforeproject(...)
command. Zephyr sets up all the toolchain related paths and this is why this order is needed, among others, I guess. Why not rely on CMake's toolchain files functionality and let user choose the toolchain on his own? Zephyr could provide toolchain files on his own that set the initial C flags and others. I think that it could simplify the build system complexity. The compiler flags and all the toolchain related boilerplate could be defined as cmake targets. This also makes the project really application-centric. In this form the coupling to the Zephyr project is quite high unfortunately.When defining multiple static library targets for which I would like to have proper compiler flags provided, I can't really do it from CMake, because Zephyr doesn't define any target that has compiler flags attached to it. Instead
COMPILER_OPT
is used, which is a string that is appended to the compiler invocation.If you really want to be application-centric don't define executable targets (like the
app
) inside the Zephyr CMake module. It is preferred to define library or interface targets, so the user could link to it easily.I couldn't use
target_compile_features
. When I usedset_target_properties(... CXX_STANDARD ...
as a workaround the flags has been ignored by the setup. This means that I can't rely on any CMake feature because I am not really sure whether I have to enable the same function from the menuconfig.My suggestion is to rework the build system step by step.
The text was updated successfully, but these errors were encountered: