Other Parts Discussed in Thread: IWR6843
Background:
There's a very helpful guide here which outlines best practices in terms of Code Composer project portability, and within that guide there's a section on sharing environment variables through use of vars/macros.ini.
From my understanding, that will work when sharing variables with different users, but does not necessarily scale when sharing them across projects.
I think the key there is that the macros.ini file has to live in the root of the project, so if you had two projects, you would have to maintain two separate macro.ini files.
“You can share variables among multiple users by defining the needed variables to an *.ini file that the user can import.
- The file can be automatically read during a project import if:
- the file is named macros.ini and
- the file is at the project root location
- Otherwise the file can be manually imported via menu File → Import → Build Variables.
- After import, the variables are set both as Path variables and Build variable”
Question:
In the case of IWR6843, generally speaking there will be two separate projects, one for MSS and one for DSS.
For portability across systems, it may be advantageous to include the SDK and SYS/BIOS within the directory that your projects live in. This could either be copied, usage of git submodules etc, but in the end, your SDK and SYS/BIOS paths would no longer live under C:/TI. As an example, this is what it could look like, where the SDK and BIOS live next to the projects:
As such the developer would have to adjust their SDK/BIOS paths to account for that.
If it's just one person working on the project, the impact is minimal, but if it has to span 12+ developers, then each developer would have to manually update these paths.
Another option could be to use macros.ini, but then you would have to maintain two versions, one for DSS and one for MSS. This could end up being a maintenance burden if more variables are added over time.
The third option, and main reason for the question is, using something similar to TI's setenv.bat script, located in C:\ti\mmwave_sdk_03_05_00_04\packages\scripts\windows\setenv.bat
I like this option most, and it's inline with what we do currently for other projects. Basically you would have one single batch script that sets up the devs environment, so they can build without issue. This also ensures everyone is using the same paths SDK versions etc.
The question is, is there a way for Code Composer to run the setenv.bat script on initialization, or opening of the projects? Or a way to point the projects to a specific vars.ini file that lives outside of the .cproject?
Alternatively, I could have each dev run the setenv script prior to opening Code Composer, but it would be ideal if they just import the project and maybe part of a pre-build step, setenv.bat is run.
That way, the paths are all set and ready to go without them having to update anything.
Curious what you think.
Thanks!
