What should I keep under git version control?

[escherstair]

After I have setup the environment as described in the wiki, and I have imported a project from the repository, I have the following folder structure project

|--- .vscode
|--- __repo__
|    |--- core
|    |--- middleware
|    |--- rtos
|--- armgcc

where the children of __repo__ are symbolic links. My question is: what should I keep under git version control for my project? What should another developer of my team do before starting working on this project? I suppose cloning my repo and what else? Setting up the environment with the extension and importing the existing project as described here?

/ EDIT / After some investigation I can add that:

• inside mcuxpresso-tools.json there are some paths that are user-dependent ("toolchainPath" and sdk "path"), and they're written as absolute paths. They depend on where the developer downloaded the toolchain and the sdk. And so it's not a good idea including them in the git repository to be shared between different developers
• inside cmake-kits.json there is the same issue on "SdkRootDirPath" and "toolchainFile" but I imagine that this file is re-generated by the extension when some task is done. Is this right? Is it safe not including this file in the git repo?
• I tried deleting the __repo__ folder (only symbolic links inside) and, apparently, everything works as expected (intellisense + build). Is this folder there only to make clearer the dependencies in the "Explorer" view?
• I tried leaving my sources only (+ armgcc folder) and using "Import Project" from the extension, but when I select that folder, I get the error Error: Selected file or folder is not a valid MCUXpresso project. But as far as I can see, the folder structure is the same as one of the examples contained in the SDK, that is the starting point for "Import Example from repository"

A lot of doubts and open questions, but I'm confident I can get the result, at the end.

[DragosMiloiuNXP]

Hi @escherstair ,

There are two options for saving an MCUXpresso SDK based project under git:

• Delete __repo__ and build folders (like armgcc/debug, armgcc/release) and keep the remaining files in git (including .vscode folder). The other developers should clone your project from git and import it using Import Project.
• Save in git the MCUXpresso Project archive (created from Projects view -> Right Click -> Project -> Export MCUXpresso Project Archive). Keeping zip files in git may not be the best option though.

Regarding paths present in mcuxpresso-tools.json and cmake-kits.json, Import Project feature should update them once the project is imported on another computer.

As you pointed out the __repo__ folder is not necessary for build, debug, IntelliSense, etc. It is added for two reasons: so, the search functionality in VS Code is able to look through SDK’s code as well whenever a developer is looking for something and, as you said, “to make clearer the dependencies in the "Explorer" view”.

PS. If you think we can improve the user experience here in any way, please do not hesitate to let us know.

[escherstair]

Hi @DragosMiloiuNXP thank you very much for your explanation.

Regarding paths present in mcuxpresso-tools.json and cmake-kits.json, Import Project feature should update them once the project is imported on another computer.

Yes, this is true, but it's no so convenient because when the developer "B" pushes his/her commits to remote, the paths are updated too. And the developer "A" will see changes... And so on.

Do mcuxpresso-tools.json and cmake-kits.json support VS code variable substitution? I mean, can I use some VS code variables (${userHome}, ${workspaceFolder}, ...) in the paths? In this way it's quite easy changing the file to avoid absolute paths.

PS. If you think we can improve the user experience here in any way, please do not hesitate to let us know.

Thank you for this opportunity. For sure I will share here my feedback, because I think that customer feedback is important to drive the development

[DragosMiloiuNXP]

Hi @escherstair,

In cmake-kits.json and mcuxpresso-tools.json you can define your paths (like: toolchainPath, sdk.path, etc.) by using the value of environment variables. Example: "toolchainPath": "%HOMEPATH%/.mcuxpressotools/arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi".

[escherstair]

Hi @DragosMiloiuNXP %HOMEPATH% doesn't work as "ARMGCC_DIR" in cmake-kits.json. When I try to configure the project with cmake I get the error

[cmake] -- TOOLCHAIN_DIR: %HOMEPATH%/.mcuxpressotools/arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi
[cmake] -- BUILD_TYPE: debug
[cmake] -- TOOLCHAIN_DIR: %HOMEPATH%/.mcuxpressotools/arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi
[cmake] -- BUILD_TYPE: debug
[cmake] -- The ASM compiler identification is unknown
[cmake] -- Found assembler: %HOMEPATH%/.mcuxpressotools/arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi/bin/arm-none-eabi-gcc.exe
[cmake] CMake Error at CMakeLists.txt:18 (ENABLE_LANGUAGE):
[cmake]   The CMAKE_ASM_COMPILER:
[cmake] 
[cmake]     %HOMEPATH%/.mcuxpressotools/arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi/bin/arm-none-eabi-gcc.exe
[cmake] 
[cmake]   is not a full path and was not found in the PATH.
[cmake] 
[cmake]   Tell CMake where to find the compiler by setting either the environment
[cmake]   variable "ASM" or the CMake cache entry CMAKE_ASM_COMPILER to the full path
[cmake]   to the compiler, or to the compiler name if it is in the PATH.

If I use ${userHome} it works

  "ARMGCC_DIR": "${userHome}/.mcuxpressotools/arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi",

Product Suggestion: Maybe ${userHome} can be automatically set by the extension (instead of the explicit path to the user home).

[DragosMiloiuNXP]

Hi @escherstair,

Thank you for the suggestion. I'll try it locally and include the fix in a future extension release. We are also working on reducing the number of absolute paths present in various json files.

[escherstair]

• Delete __repo__ and build folders (like armgcc/debug, armgcc/release) and keep the remaining files in git (including .vscode folder). The other developers should clone your project from git and import it using Import Project.

I've just tried, but when the developer 'B' imports the project through Import Project, __repo__ symbolic link is not created (under Windows 11, at least). He had to create it manually with an elevated command prompt mklink /d "Link" "Source Target"

[DragosMiloiuNXP]

Hi @escherstair,

In the latest version of the extension we reduced the number of absolute paths in our JSON files. Please refer to the documentation here, or import a new example to see the updates.

[escherstair]

Hi @DragosMiloiuNXP I see some improvements, but something else doesn't work as expected:

• When I select project context menu -> Configure -> Associate Toolchain mcuxpresso-tools.json is changed, but "toolchainPath" is filled with the absolute path, and doesn't use ${userHome} as described here
• the same variables are not used in ide_overrides.cmake (SET(ARMGCC_DIR ...), SET(SdkRootDirPath ...), SET(POSTPROCESS_UTILITY ...)) where the absolute paths are used (and ide_overrides.cmake is under git control, becausde I need it qhen the CI/CD pipleine check-outs the repo to build the firmware from the CLI). I see that the paths are set every time I press the build button in the PROJECTS window

[DragosMiloiuNXP]

Hi @escherstair

• You are right. The paths in mcuxpresso-tools.json are absolute paths when the project is created or the repository or toolchain are changed. What we did was the ability to manually change the absolute paths to relative paths by using variable substitution described in doc. What we can do is try to come up with an algorithm to use variables instead of absolute paths, but this won't be 100% possible.

For example, let's say the toolchain is located somewhere under your userHome folder. Then we can determine that and set the "toolchainPath" as a path relative to ${userHome}. If it's not under userHome, we can try to set it as relative to ${workspaceFolder}. Even with this approach it won't handle all the cases. For example you may have your project on drive C and the toolchain or repository on a different drive (or even mapped network drive).

• The purpose of ide_overrides.cmake is to allow users to build their projects directly from command line. So, since the VS Code is not involved, there is no one to expand the variables. But you can add this file to gitignore since it is regenerated automatically.