This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VSCode Pristine Build puts Zephyr .config back to default

Hi All,

Likely because I am still quite new to this, but I have started with MQTT simple example and whenever I do use GuiConfig to make mods, it saves them to

proj/build/zephyr/.config

and moves the old one to 

proj/build/zephyr/.config.old

However, because these are in the output folder, if I were to do a pristine build for whatever reason, this gets deleted and I either need to overwrite it with a backup copy or make the changes once more. Is there a more streamline process to this? Perhaps I skipped over some documentation somewhere?

Following the above, if I were to commit code, since the selected board is selected and also in the build folder, what should I be adding to repo for BSP? or generally, does everyone just do a file ignore for *.d, *.a, *.cmake etc and keep the empty output folders?

Kind regards,

Ryan.

Parents
  • Hi Ryan,

    Is there a more streamline process to this?

    You are right that any changes you make with guiconfig is in the build folder, and therefor lost whenever you do a pristine build (see Changing the configuration temporarily). This means that guiconfig is good for browsing configuration options and dependencies and test this out, However, to make changes persistent you should do the configuration changes elsewhere, typically in prj.conf (see Changing the configuration permanently).

    Following the above, if I were to commit code, since the selected board is selected and also in the build folder, what should I be adding to repo for BSP? or generally, does everyone just do a file ignore for *.d, *.a, *.cmake etc and keep the empty output folders?

    If the question is if you need to keep anything from the build folder, then the answer is no. If you configure your project correctly everything in the build folder is build artifacts. And which board you build for etc is something you specify when you build, so there is no need to keep the build folder for that. If I misunderstood the question, perhaps you can elaborate?

    Einar

  • Hi Einar,

    Thanks for following up!

    Yea I found the options I was after and I ended up just putting them manually into my prj.conf file as you mentioned. I am happy to do this as a work around for the moment as I don't need to customise the zephyr OS more than the default, though would be good for something more persistent in the future?

    If the question is if you need to keep anything from the build folder, then the answer is no. If you configure your project correctly everything in the build folder is build artifacts. And which board you build for etc is something you specify when you build, so there is no need to keep the build folder for that. If I misunderstood the question, perhaps you can elaborate?

    Yea it was if I wanted to commit all my code into a git repo, I was hoping to not have to touch the board selection etc in the future, so I may end up commiting some items from the build folder to maintain the same BSP across machines in case someone makes a change etc. Was there any suggested way to do this? Or currently recommended to only upload the code and recreate the target board after pulling code?

  • Hi,

    rfleming said:
    though would be good for something more persistent in the future?

    What I described is the persistent approach that is used across Zephyr and I do not believe there are any plans to do this differently in the future.

    rfleming said:
    Yea it was if I wanted to commit all my code into a git repo, I was hoping to not have to touch the board selection etc in the future, so I may end up commiting some items from the build folder to maintain the same BSP across machines in case someone makes a change etc. Was there any suggested way to do this?

    You need to specify the board type when you build the first time after a pristine build, as you have noticed. But that is all. Any configurations etc can be kept outside of the build folder. If you for instance us a DK or other supported board and just want to make some changes, you can use a device tree overlay file. For a custom board you should make a board file for that, typically within your project. See the Out Of Tree Board sample. These files should be part of your application project an be checked in to your repository - they are not part of the build folder, but are used by the build process. PS: nRF Connect for VS code has a board creation wizard, which helps you create a board if you select "Create a new board".

Reply
  • Hi,

    rfleming said:
    though would be good for something more persistent in the future?

    What I described is the persistent approach that is used across Zephyr and I do not believe there are any plans to do this differently in the future.

    rfleming said:
    Yea it was if I wanted to commit all my code into a git repo, I was hoping to not have to touch the board selection etc in the future, so I may end up commiting some items from the build folder to maintain the same BSP across machines in case someone makes a change etc. Was there any suggested way to do this?

    You need to specify the board type when you build the first time after a pristine build, as you have noticed. But that is all. Any configurations etc can be kept outside of the build folder. If you for instance us a DK or other supported board and just want to make some changes, you can use a device tree overlay file. For a custom board you should make a board file for that, typically within your project. See the Out Of Tree Board sample. These files should be part of your application project an be checked in to your repository - they are not part of the build folder, but are used by the build process. PS: nRF Connect for VS code has a board creation wizard, which helps you create a board if you select "Create a new board".

Children
No Data
Related