The issue lies in the "Kconfig" for the "sdk-*" repositories.
When you clone them, the folder name is "sdk-*" (eg. "sdk-nrf").
But the Kconfig contains 'source "${ZEPHYR_BASE}/../nrf/subsys/fw_info/Kconfig.template.fw_info_ext_api"'. Note the "/nrf/" path != "sdk-nrf".
So if I:
$ git clone https://github.com/nrfconnect/sdk-zephyr.git
$ git clone https://github.com/nrfconnect/sdk-nrf.git
$ cd ./sdk-zephyr
$ cmake -B build -DCROSS_COMPILE=/usr/bin/arm-none-eabi- -DBOARD=nrf52840dongle_nrf52840 -DCMAKE_PREFIX_PATH=<pathTo>/sdk-zephyr -DZEPHYR_MODULES="<pathTo>/sdk-nrf/" samples/hello_world/
I get:
...
-- Including generated dts.cmake file: <pathTo>/sdk-zephyr/build/zephyr/dts.cmake
warning: HAS_NORDIC_DRIVERS (defined at modules/hal_nordic/Kconfig:7) has direct dependencies 0 with value n, but is currently being y-selected by the following symbols:
- SOC_SERIES_NRF52X (defined at soc/arm/nordic_nrf/nrf52/Kconfig.series:6), with value y, direct dependencies <choice> (value: y), and select condition <choice> (value: y)
...
When I rename that "sdk-nrf" folder to "nrf", I get past that issue, and on to another one:
...
-- Including generated dts.cmake file: <pathTo>/sdk-zephyr/build/zephyr/dts.cmake
warning: the hex symbol NRF_MODEM_LIB_SHMEM_CTRL_SIZE (defined at <pathTo>/nrf/lib/nrf_modem_lib/Kconfig:109) has a non-hex default NRF_MODEM_SHMEM_CTRL_SIZE (undefined)
...
Since I see that value exists in sdk-nrfxlib, I rename that folder and at it to DZEPHYR_MODULES which then results in:
-- Zephyr version: 2.6.99 (<pathTo>/sdk-zephyr), build: e0448d102b8e
CMake Error at <pathTo>/sdk-zephyr/cmake/zephyr_module.cmake:61 (message):
Unmet or cyclic dependencies in modules:
<pathTo>/nrfxlib/ depends on: ['hal_nordic']
...
So, before, "NRF_MODEM_SHMEM_CTRL_SIZE" was "undefined". And then when I add the module that defines it, it then complains about circle-dependency?
That does not appear to be related to https://devzone.nordicsemi.com/f/nordic-q-a/77751/sdk-v-1-6-project-creation-issue/321288#321288, as I had tested it by putting it all in /wtf/.
I guess as another heads-up (not yet an issue?):
Including boilerplate (Zephyr base (cached)): <pathTo>/sdk-zephyr/cmake/app/boilerplate.cmake
CMake Deprecation Warning at <pathTo>/sdk-zephyr/cmake/app/boilerplate.cmake:37
(cmake_policy):
The OLD behavior for policy CMP0079 will be removed from a future version of CMake.
The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
<pathTo>/sdk-zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
<pathTo>/sdk-zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
CMakeLists.txt:5 (find_package)
