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:

- add_subdirectory(${SOC_SERIES})

+ add_subdirectory(${CONFIG_SOC_SERIES})

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>`.
Only the `SOC_SERIES` is a little special, as that is copied into a local variable (history goes before my time).

https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/app/boilerplate.cmake#L532

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.

But using `SOC_SERIES` should work for files included as part of Zephyr CMake boilerplate (everything that is happening as part of `find_package(Zephyr)`).

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.