zephyr_library_*() configuration has lower precedence than global zephyr_*() configuration #5097
Assignees
Labels
Comments
|
Source file flags have higher precedence than link interface flags, so reworking the extentions to use source file properties might be the cleanest solution. |
SebastianBoe
added a commit
to SebastianBoe/zephyr
that referenced
this issue
Nov 22, 2017
This fixes zephyrproject-rtos#5097. The desired behaviour is that when a flag that is given through the zephyr_* API conflicts with the zephyr_library_* API then precedence will be given to the zephyr_library_* API. In other words, local configuration overrides global configuration. We choose to rely upon the compiler for sane behaviour when flags are in conflict. Compilers generally give precedence to flags given late on the command line. So to ensure that zephyr_library_* flags are placed late on the command line we create a dummy interface library and link with it to obtain the flags. Other options were considered, source file properties would also have higher priority. But that would have required some kind of post-processing stage that applies all the source file properties. Linking with a dummy interface library will place flags later on the command line than the the flags from zephyr_interface because zephyr_interface will be the first interface library that flags are taken from. Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
nashif
pushed a commit
that referenced
this issue
Nov 23, 2017
This fixes #5097. The desired behaviour is that when a flag that is given through the zephyr_* API conflicts with the zephyr_library_* API then precedence will be given to the zephyr_library_* API. In other words, local configuration overrides global configuration. We choose to rely upon the compiler for sane behaviour when flags are in conflict. Compilers generally give precedence to flags given late on the command line. So to ensure that zephyr_library_* flags are placed late on the command line we create a dummy interface library and link with it to obtain the flags. Other options were considered, source file properties would also have higher priority. But that would have required some kind of post-processing stage that applies all the source file properties. Linking with a dummy interface library will place flags later on the command line than the the flags from zephyr_interface because zephyr_interface will be the first interface library that flags are taken from. Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It is expected behaviour that if a "global" flag from zephyr_compile_options() conflicts with a library-specific flag given with zephyr_library_compile_options() then the local library-specific option will override the global option.
An example of a use-case is that we are able to globally configure whether we build optimized for size or speed, but the bluetooth controller is on the limit of it's real-time requirement and must therefore always be built for speed. https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/CMakeLists.txt#L36
Now, CMake has no idea what flags conflict with each other, so it can't help us, but GCC does, and it gives precedence to the flag specified last on the command line. So it is a simple matter of ensuring that zephyr_library_* adds flags later on the command line than zephyr_*. But unfortunately CMake places flags from link interface libraries after a target's flag's.
The text was updated successfully, but these errors were encountered: