Which files to commit to code repository to save build information (VS Code and git)

[CktDesigner]

I'm trying to commit a VS Code project to source control and don't want to include the entire build directory (with all of the build-generated files).   But it seems that all of the information about the build configuration is stored in the build directory.  Is there a definitive list of files necessary (to save in a repository) to allow a successful build when cloning the project?

Thanks!

[Einar Thorsrud]

Hi,

You should not commit anythign within the build folder. It is generated for every clean build. The build configuration is normally not checked in, and typically only involves a few parameters (often only the board). That could be communicated via a README file or similar. I suggest having a look at Creating an application.

You can refer to the example applications in the SDK for a reference of files that are needed (minimum is a CMakeLists.txt file and prj.conf, and one or more source files, typically a main.c).

[CktDesigner]

I already have a project that builds (and was migrated from the older Segger environment).

I also know that I shouldn't commit anything from the build folder.   My point was that if the build folder is removed (or not there because it wasn't cloned from a repository), some of the information needed to create the build is lost.    I want to be able to have someone else clone my repository and do a simple build without having to configure anything.

[For example: My code is for a controller in a much larger, complex system.   Those who are testing, debugging, or calibrating the other parts of the system simply want to be able to get the most recent (or appropriate version), build it and get on with their part of the system without having to deal too much with the IDE.]

The old system (Segger) had the projectName.emProject file that contained configurations (plus lots of other information) that allowed, for example, a "Debug" configuration and a "Release" configuration (or any other configuration that was needed).

How can this be done in the VS Code environment?

[Einar Thorsrud]

Hi,

You can have separate debug and reelse configurations (and others) with the VS Code environment as well. This is normally handled by using additional configuration files. For instnace, if you have a debug.conf that adds debug options you can add that on the command line by appending  -- -DEXTRA_CONF_FILE='debug.conf' to the west build command. From nRF Connect for VS Code, you add an extra configuration file here when making the build configuration:

[CktDesigner]

Understood...  Still doesn't help the situation where the project is cloned from Git (by another user) who has to create a configuration before building...   

[Einar Thorsrud]

Any changes they want persistent should be in an overlay file or Kconfig file (like prj.conf), there should not be any need to keep any files from the build folder (if it is, for instance because Kconfig files in the build folder has been modified, those changes (if any) should be copied out of the build folder and into the prj.conf file or similar.

[CktDesigner]

This is understood.

But I think you might be missing my original question.

I have a project that compiles in VS code using the Nordic nRF Connect extension.

I want others to be able to clone the project (using git) and have a build configuration available.   I don't want them to have to go through the "add configuration", etc.     All of the build information seems to be saved in the build folder specified during the "add configuration" process.    I agree that the build folder shouldn't be included in the git commit.   But there should be a mechanism (other than a README that explains how to fill out the "add configuration" window) for defining one or more build configurations that can be part of source control saves.

I don't see a way to do this using the currently recommended VS Code procedure.

I could do this when I was using the Segger IDE.

Thanks...

[Einar Thorsrud]

Hi,

I understand. However, that is not supporter (nor a request we see often). Perhaps you can elaborate on why you want the build configuration checked in? You can include moset configurations you want in the normal configuration (devictree or Kconfig) files, and and alternatively also in the CMakeLists.txt file for some special cases. And then someone building will typically jus thave to specify the build target board.

[CktDesigner]

Perhaps I'm missing something...

My code is for a controller in a much larger, complex system.   Those who are testing, debugging, or calibrating the other parts of the system simply want to be able to get the most recent (or appropriate version), build it and get on with their part of the system without having to deal too much with the IDE.

So I would like to be able to define some configurations (ie. Debug1, Debug2, Release), and provide very simple instructions (as the others using the system are RF and Mechanical engineers) to clone the project, the open the project folder in VS Code, select the appropriate target (via  selecting the appropriate build), and click the "build" button.

Is there a different way to do this, where creating a "build" configuration for use by VS code is not needed?

Thanks...