• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 581 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Best practices for controlling and sharing TI supplied tools across multiple developers and projects

Richard Zuber
Prodigy 210 points
Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

Hello,

I'm hoping to get a sense of what the best practices the community has found for source controlling and sharing the various TI supplied tools within their organization.

Our company is just starting to use TI DSPs & SYS/BIOS, so we have a lot of levity to try to organize things “the right way”.  The DSP chips will be used across multiple programs that have independent purposes / release schedules / developers.  As much as possible, we’d like to share and maintain compatibility across the programs (ie: if a bug is fixed one place, everyone gets the fix with minimal effort). 

Our current plan is to create a common repository where code will be shared across all programs, with program specific code being in separate branches.  The common repository will hold all custom drivers, platforms, shared message structures, interfaces, utilities and functions.  Logically, the common repository will be divided into sub-branches "dev", "main", "rel".  Main will be the standard branch to which programs link.  If a change has to be made to the repository, it will be developed under dev and then pushed up to main.   Program specific code will be held in a separate repository and be a client to the shared repository.  When a project has to release, a release branch will be made (using the standard RTSC M_S_R_P nomenclature).  If a released project needs to make updates to the common repo, it must follow the standard dev-main-release cycle, thus picking up all other changes made.

The big question now is how we should control the TI supplied tools such as BIOS6, XDCTools, IPC, and compiler versions.  I'd like to have everyone keep as up to date as possible, but it would be unrealistic to expect each developer to keep their local versions updated to whatever the latest common repository build is using.

Option 1 would be to source control all the TI libraries as they are released.  Each time updates are downloaded, they would be integrated to source control.  Instead of using the top level name (for example bios_6_30_03_46), the new code would be integrated to a generic folder (bios_6).  The changelist description would annotate the full release path name (bios_6_31_4_27).  The build scripts for the common repository would have to use environment variables that point to the source controlled versions of the tools rather than the standard XDCPATH and XDCROOT.  Individual programs could update tools as they see fit, or merely use the same tools as what the common repository is using (most likely).  I’m not sure if there are any issues I’m neglecting by sidestepping the standard XDCPATH/ROOT variables in this case.

Option 2 might be to coordinate an “update day”.  Say on the first of the month every developer grabs the latest updates in CCS4 (perhaps with a reminder via our mailing list).  I don’t like this because it is not automated, but could be a less invasive way of handling updates.

Option 3 would be to force a version of the tools (say what is included on the Code Composer DVD), and forbid developers from upgrading tools.  This sidesteps the problem completely, but causes us to miss out on bug and performance improvements).

I'm tending to lean towards option 1 at the moment.

Any insights or examples on how this issue has been handled by your organization are much appreciated.

  • 0
    TI__Guru**** 163015 points

    Richard,

    Are you using projects in CCS or makefiles?  One thing to note is that projects in CCS store the version of the compiler, XDC and BIOS they are configured to use.  So if you are using BIOS you would need to make sure the project properties were updated when you put a new version in source control.  If the projects themselves were going to be in source control you could check them out make the update and check them back in so that everyone would get the change.  However for each individuals CCS to be aware of the new tools (compiler, BIOS...) you would need to make sure that their CCSs are configured to search in the location where you are installing the new tools.  If you have done that they CCS should automatically discover the new tools and be able to use them without any user interaction.  I just tried this in my v5.01 install.  I setup a search path for the \tools\compiler folder of my 4.0.2 install and it found all the compilers inside (the actual compilers are in \tools\compiler\ISA\), I tried specifying the root of the 4.0.2 install but that was too many levels apart.

    I will leave this in the CCS forum for a day for others to comment and then move it into the BIOS forum to see if the RTSC experts have any inputs.

    Regards,

    John

  • 0 in reply to JohnS
    Prodigy 210 points

    John, thanks for your reply.

    I should have mentioned we are using CCS 4.2.1.00004

    We are open to using whatever is the easiest method (be it makefiles or Eclipse projects) to accomplish the desired goal.  Right now I have a project that runs "xdc -PR ${REPO_DIR}" as a pre-build step to build the common repository before creating its own program.  I plan on using Eclipse projects for the top level our various programs.  These would be in source control (following the guidelines found elsewhere for what and what not to check in).   I do see the .cdtbuild file has the pointers to the tools versions as you mentioned.

    Are you recommending that the common repository also be an Eclipse project, and let the metadata choose the tools to compile against?  Is source controlling the TI repos a good idea in this case?  The problem with letting the project file determine the version is that if a developer hasn't updated, their code won't compile.  The plus side to source controlling is that code will always compile from source control no matter how the developer has CCS4 updated.  It would also make building old versions out of source control painful.  Imagine a scenario where we had to replicate a build from a year ago on a new machine.  CCS4 would want to update all the way to the latest version, even though we need something in the middle.  Not sure if this a compelling enough reason to go this route however.

    Ideally the final solution would be some sort of a "set it and forget it" style thing that is setup when a new developer starts developing for the DSP chip.  For example they would set an environment variable or something and never have to worry about it again.  Also I am trying to ensure that no absolute paths need to be used anywhere to ensure ease of portability throughout developer machines.  One solution I have decided on for project files is to use macros.ini.  A base macros.ini.base file would be checked into source control.  When first obtaining the project, the developer would have to copy this file as macros.ini and replace the paths found in it to their local mapping.

    Like I said, I'm interested to see how others are doing this as a kind of sanity check to make sure I'm not missing a simple solution.