Re: SOC_DIR not populated
Thanks for the confirmation of the patch.
And thanks for the update.
I was waiting for confirmation before sending update on mailing list.
See more comments below.
From: Dan Kalowsky <dank@...>
Sent: 11 August, 2020 0:37
To: Rasmussen, Torsten <Torsten.Rasmussen@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@...
Subject: Re: [Zephyr-devel] SOC_DIR not populated
Sorry for the delay in response, got pulled into other duties and was not able to follow up on this in the immediate time frame.
On Thu, Aug 6, 2020 at 11:27 PM Rasmussen, Torsten <Torsten.Rasmussen@...> wrote:
Thank you for this PR. More importantly, thank you for fixing the documentation in the follow up PR and pointing out that this is a breaking change for others.
One additional note that should be added here, when using the files as corrected to build, they fail to find the linker.ld file found in the soc_a in the example.
The fix is to change the arm/product/CMakeLists.txt file like so:
This seems to allow everything to work correctly in the compile time frame. You may want to include that detail as well if it is correct. Note the demo repo needs to be cleaned up to compile anything at all, don't trust it. This seems odd because I believed that Zephyr dropped the CONFIG_ prefix from everything internally before using it, yet in this case the variable has data only when prefixed.
No, all Kconfig settings in CMake must be accessed using `CONFIG_<name>`.
I would discourage using `SOC_SERIES` directly and instead do the proper `CONFIG_SOC_SERIES` but I will not remove `SOC_SERIES` possibility without a good reason, cause users may depend on it.
Which is the case for `SOC_ROOT/arch/soc` included CMake files.
For other usage, such as if a CMakeLists.txt file is included as a `add_subdirectory()` after `find_package(Zephyr)` then `SOC_SERIES` cannot be used due to CMake scoping, and `CONFIG_SOC_SERIES` must be used.
That has not changed, so I would like to know how you get those CMake files included, to understand if there is an issue hidden somewhere.
This should not have changed behavior with the changes introduced by https://github.com/zephyrproject-rtos/zephyr/pull/26715 .
I had no problem with linking when building for nrf52840dk_nrf52840 board, but I had to set `import:true` in the west.yml to get Nordic hal headers.
But you might be looking at code that you have not pushed to the repo.
At least I don’t see any board using the `soc_a` SoC.
Thank you for the history. From my island, I don't see this as a correct usage/behavior, but I am clearly in the minority.
See note above.
"Do you expect me to talk?"