Problem building with application west.yml in ncs-v1.5.1

[Jens Cameron]

We have developed an application in ncs-1.3.0 where we created a west.yml file for the application that lists nrf, zephyr and other dependent repositories. We have downstream clones of all relevant repos to be able to put our corporate fixes into the source without clobbering public repos.

When upgrading to ncs-1.5.1 this apparently does not work, build fails.

Building the formware appears to require the nrf/west.yml to be the initialized west.

Replacing our west file with the nrf/west builds but changing the self:path: from nrf to something else fails to build.

We have tried a simplistic application west file that just imports the nrf/west.yml. This fails to build.

Using our custom application/west.yml fails with different error, semms to indicate that boilerplate.cmake is imported twice.

Apparently the west file is not only for synchronizing repositories but also part of the build process.

We need is to have downstream clones of all repos for our own fixes. How do we accomplish this, preferrably with a minimum of commits into the downstream repositories and with the application sync'd with commits in other repos?

[Jens Cameron]

Hi

I believe I have resolved the issue.

I have inherited the project and it turns out our application repository contained a zephyr folder with a module.yml file. 

My interpretation is that this caused a circular dependency between the application and zephyr, causing the boilerplate.cmake to be included twice from the same project. Thereof the errors about duplicate targets.

I don't know if the zephyr folder made any sense in ncs-v1.3.1 or if it was just garbage from some example code.

You may close this ticket.

Thanks for your help.

--Jens

[Torsten Rasmussen]

Hi Jens,

Great that you found the issue 

I have inherited the project and it turns out our application repository contained a zephyr folder with a module.yml file.

and that is perfectly legal, but of course you need to check what that CMakeLists.txt file does.

I did some examination of the `cmake.log` file. Thanks for that, it was really helpful.

And when reading that, I notice, as you also have found, that your application repo is also a Zephyr module:

# Beginning of your application.
1 .../uma_nrf52840_app/applications/uma/CMakeLists.txt(7): cmake_minimum_required(VERSION 3.13.4 ) 
2 .../uma_nrf52840_app/applications/uma/CMakeLists.txt(11): set(BOARD_ROOT .../uma_nrf52840_app/applications/uma/../.. )
....
# Zephyr package is being looked up, good.
14 .../uma_nrf52840_app/applications/uma/CMakeLists.txt(71): find_package(Zephyr REQUIRED HINTS C:/workspace/ncs2/zephyr )
...
# Zephyr modules being processed, in this case your app repo.
238902 .../zephyr/CMakeLists.txt(458): if(NOT .../uma_nrf52840_app STREQUAL ) 
238903 .../zephyr/CMakeLists.txt(459): set(ZEPHYR_CURRENT_MODULE_DIR .../uma_nrf52840_app ) 
238904 .../zephyr/CMakeLists.txt(460): set(ZEPHYR_CURRENT_CMAKE_DIR .../uma_nrf52840_app ) 
238905 .../zephyr/CMakeLists.txt(461): add_subdirectory(.../uma_nrf52840_app .../uma_nrf52840_app/_build_uma_nrf52840_uma_ep2_Debug/modules/uma_nrf52840_app )
238906 .../uma_nrf52840_app/CMakeLists.txt(1): cmake_minimum_required(VERSION 3.13.1 ) 

# whoops, a second find_package(Zephyr ...) that doesn't look good.
238907 .../uma_nrf52840_app/CMakeLists.txt(2): find_package(Zephyr REQUIRED HINTS C:/workspace/ncs2/zephyr )

so that seems to be your problem indeed.

Note, that set(BOARD_ROOT ...) is not needed, you can specify your module to have a board root and avoid such code in the application CMakeLists.txt.
Just do the following in your module.yml in `uma_nrf52840_app/zephyr/module.yml

build:
  settings:
    board_root: .

that will pickup additional boards from `<board_root>/boards`.

See more here:
http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/modules.html#build-settings

My interpretation is that this caused a circular dependency between the application and zephyr, causing the boilerplate.cmake to be included twice from the same project. Thereof the errors about duplicate targets.

No, the problem seems to be that the included code contains a second `find_package(Zephyr)`.

Best regards

Torsten