Sharing vscode projects on several computers

[Edge30]

I'm using the vscode extension to create projects.

I start by importing several sample projects, this works perfectly and I get the new projects in my workspace. I work on them, make changes, build, flash, debug. It all goes well.

I use a version control system (git), I later need to open the very same project on another machine.

So I commit the whole workspace folder to git.

I go to the other machine, open vscode, and then I add the same folder from git. The projects are added to the workspace however they don't show up in the NXP extension tools. The NXP extension doesn't recognizes them as NXP vscode projects. So I cannot build/debug/flash.

If I try to manually 'import a project', vscode doesn't recognice any of the project folders (where the main app .c files are), if I point the the armgcc folder inside them vscode recognices and imports it, but this subfolder is useless without it's parent.

So, what's the expected procedure to import an existing project created from the samples that come with the sdk?

Thanks

[Edge30]

It is not an SDK issue, in fact I just found I can reproduce it on the same machine.

- Use the NXP extension's "import example from repository" to create a new project

- Work on it, just to ensure it works ok.

- Remove the project from the vscode workspace (not from the disk, only from the vscode exporer)

- delete the .vscode folder inside the project folder in the disk. (according to vscode documentation, this folder is system specific, so it can be re-created any time a project is imported.

- Use NXP Extension's "Import Folder" feature to re-import the project <---- issue: the tool cannot detect that this is a project, doesn't let import

- Manually add the project folder to vscode using vscode's 'add folder to workspace' feature.

- Look in the NXP extension's section <-- issue: the project added doesn't show, it is not recognized by the extension.

- Now recover the .vscode folder from trash.

- Repeat the NXP extension's import step <-- now it works ok again.

Essentially, .vscode is needed for the NXP extension to recognize the project. However, this goes against vscode's operation mode, where it says that the .vscode is not needed to import a project.

The solution for now is to include the .vscode when sharing projects. I also confirmed this using git: adding the .vscode to the commit the project can be imported on another machine. In my case, my two machines are similar so no changes to .vscode are needed, however I suspect moving to a different OS will require some manual tweaking of the .vscode.

I also found that, in the workspace folder in the disk, there're several hidden folders created by the extension, so there may be other features affected if those are not included in the commit.

While this can be worked out by manually editing the .vscode content, this makes sharing projects among team members a complication. Don't know what's NXP's take on this but it'd be important that they come out with some documentation recommeding strategies for project sharing.

[cristiantepus]

Hi,

1. The intention is to keep .vscode content when saving a project (to git or any other storage) as it contains useful build&debug configurations. Still, removing the .vscode directory then obtaining error when reimporting it is a bug and we will fix it.

But keep in mind, even if the importer will be able to successfully import it after the fix, not all configurations can be automatically restored (like any previous debug (probe) settings manually added in launch.json, original sdk information, special types for the project like multicore/trustzone which were saved when project was created, etc)

2. Our recommendation to deal with moving a project from one machine to another is to use "Export MCUXpresso Project Archive" option to generate an archive that is intended to be imported to another machine (see https://github.com/nxp-mcuxpresso/vscode-for-mcux/wiki/Create-Project#export-a-project)

Regards,

Cristian

[ErichStyger]

>> (according to vscode documentation, this folder is system specific, so it can be re-created any time a project is imported.

Many things like the launch.json do not get automatically created, but contain important information you want to share with your git repository. So as it is for the JSON files with the project settings and for things which are non-machine specific, you definitely want to keep them and share them with a version control system.

I see that Microsoft might have had the intention at that the .vscode folder could be ignored by git. But the reality today with the current extensions even with the ones from Microsoft is different.

So you have to use an approach as outlined in https://bobbyhadz.com/blog/what-is-vscode-folder

I hope this helps,

Erich

[ErichStyger]

If you are using the standard projects, then they have a <JUNCTION> link to the SDK in it. If you commit such a project to git and use it on another machine, then unless you have that SDK in that same folder, it won't work and build.

What I'm doing instead is having the sdk as a physical folder inside the project, that way the project is portable and self-contained. You can see one of my examples on GitHub here:

https://github.com/ErichStyger/MCUXpresso_LPC55S16_CI_CD

I hope this helps,

Erich