How to apply changes to an nRF Connect SDK driver file from a Workspace App Repo?

[Saxman58]

The text for the recommended nRF Connect SDK workflow (using a Workspace Application Repository - https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/dev_model_and_contributions/adding_code.html#dm-workflow-4) states:

"An additional possibility is to take advantage of west to manage your own set of repositories. This workflow is particularly beneficial if your application is split among multiple repositories or, just like in the previous workflow, if you want to make changes to one or more nRF Connect SDK repositories, since it allows you to define the full set of repositories yourself."

Can you provide some instruction on the best way to do this?  For example, if I want to tweak the code in a driver source file in:

ncs/v2.6.1/nrfxlib/nrf_wifi/fw_if/umac_if/src

is there a way to make that change in my own workspace that would override or replace the original file in the Nordic/Zephyr source files so the edits would be part of my project and git repository?

I found this Devzone thread that suggests making a fork of the nRF Connect SDK, but that might be a lot for small edits of just one or two files.  And one of the commenters suggests adding a line to CMakeLists.txt that copies the modified file over the original as needed.

 Custom implementation for a source file in the NRF connect SDK/ Zephyr 

But the fork approach is the 3rd of the 4 workflows discussed at the first link above (https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/dev_model_and_contributions/adding_code.html#dm-workflow-4) and the text recommends the 4th option with the Workspace App Repo and makes it sound like you can accomplish the same thing ("just like in the previous workflow" referring to option 3 which is forking the SDK) in a cleaner way.

I've already implemented the changes in the SDK folder (with a separate freestanding application) and they work great.  But that puts them outside of my normal version control, vulnerable to be overwritten by west updates, and not easy to transfer to other developers.  What is the recommended best practice to edit a file in the SDK and bring it into control of our workspace repo?

It looks like the VS Code "Create a new application" creates a fork of the associated SDK as a west workspace and puts the example application in a folder within the workspace.  But the ncs-example-application and many of the SDK folders (such as nrf_xlib) have their own .git, so separate repositories.  I see some possible options, but don't know the best way:

1. reassign the git remote for nrfxlib to manage as my own repo, like a fork
2. put the whole SDK and application under our own repo control, like a HUGE fork
3. Preferred (if possible) - create local files within the ncs-example-application (and git repository) that override and take the place of selected driver files from the nrfxlib folders
4. Create a new device, copying all of the driver code to local folders and then modifying one or two files  (This option seems much more difficult for the Wi-Fi drivers than the BME280 example, but maybe I'm wrong since the mods are small.)

[Hieu]

Hi Saxman58,

I think first we need to revisit how the SDK and a West Workspace project work. They are built up of different parts, all of which are git repositories themselves. 
Which repositories, where they are located, and which branch/fork/tag/commit should be used are all configured in the west manifest.
The west tool uses git in the background to clone the repository during west update, and creates the SDK, or the Workspace.

For more information, I recommend going over the application development guide of both NCS and Zephyr.

The above nature of the SDK and a Workspace is how you can use your own fork of the relevant SDK part and make your own modification. 
After creating the fork, you simply modify the west manifest to point to your fork instead of the original. That is why forks work with both Workflow 3 and 4.
This is the intended/by-design way to run a project with modified SDK file.

For your example, you want to change a file in nrfxlib and you have a workspace project following Workflow 4. The application is based on the NCS Example Application.
Notice the NCS Example Application's west manifest includes a single project: sdk-nrf.
Then notice the sdk-nrf repo's west manifest includes a nrfxlib project.

In this case, you will need to have a fork of sdk-nrfxlib, and a fork of sdk-nrf.
In your sdk-nrfxlib fork, you will need to make your desired changes.
In your sdk-nrf fork, you will need to update the west manifest to use a branch or tag on your sdk-nrfxlib fork for nrfxlib.
Finally, in your project manifest, you will need to update the west manifest to use a branch or tag on your sdk-nrf fork for NCS.

That can be a lot of work for sure. If it seems so, then you can use the CMakeLists file change approach you linked. It is reasonable.

Hieu

[Saxman58]

Thank you so much Hieu for the prompt and detailed reply.  I believe I understand, and am in the process of reading more from the links you reference before I start making the changes.