• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 623 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.

CODECOMPOSER: Hard coding product paths in project

Bert
Prodigy 130 points

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: SYSBIOS, CCSTUDIO

When opening up a project, and navigating to the build settings, there's an option to have Code Composer Discover different products associated with the project.

For example:

Technically, you could manually go in, add a 'discovery path' refresh, and then assuming it detects the product in the path, it would install that particular product.

However, imagine the use case where you had 10+ developers working on the same project that requires specific versioned products i.e XDCTools 3.x.x, mmWave SDK 3.4.x, SYSBIOS 6.73.x. Each one of these products lives in some custom directory, i.e not under C:\ti. For example, c:\git\TI_Tools\XDC, c:\git\TI_Tools\SYS_BIOS, c:\git\TI_Tools\mmWave etc.

In that case, each of the devs would have to perform the manual step of adding the discovery paths.

Instead, I would like to avoid the discovery process altogether, and hard code the paths, and associated versions of the products in question.

The end result is, a developer could simply open the project and start working without having to configure specific paths and versions.

I've look at both the .cproject and .ccsproject, but I didn't see anything that jumped out.

Does anything come to mind?

Thanks!

  • 0
    Guru 13202 points

    Rule #1
    Install into C:\TI

    There is much less joke here, as it might seems at the first glance...

    I have a machine, where for the reasons out of my control I can't afford anything besides Windows at my C: drive, but plenty space elsewhere. Believe me, I regret for that situation every time.

    Preconfigured virtual machine to be distributed among developers might be a one of solutions.

  • +1
    TI__Guru**** 163095 points

    Bert,

    CCS intentionally does not store absolute paths to software in projects.  For each software product (SDK, BIOS...) and each tool (compiler, XDCTools) the project will store that the product is used and the version of the product that is used.  An individual users CCS installation then is aware of what products are installed on that particular machine.  This is done to make projects portable across different users machines (different paths) and host operating systems.  Similarly it is recommended to use variables in include paths so that absolute paths are not used.  https://software-dl.ti.com/ccs/esd/documents/ccs_portable-projects.html

    The discovery should only have to be done once per CCS installation.  If the paths are common across user installations it would be possible to setup a little script that users could run after installing.

    https://software-dl.ti.com/ccs/esd/documents/ccs_projects-command-line.html

    For example you could have batch file or script that ran a command like this:

    eclipsec -nosplash -data <workspace> -application com.ti.common.core.initialize -ccs.productDiscoveryPath "<path1>;<path2>"

    <workspace> would be the path to the workspace that will be used.   

    <path1>... would be the locations to add to the discovery path

    You could even run a command to import a set of projects into the workspace

    eclipsec -nosplash -data <workspace> -application com.ti.ccstudio.apps.projectImport -ccs.location "C:/proj1" -ccs.location "C:/proj2"

    Regards,

    John

  • 0 in reply to JohnS
    Prodigy 130 points

    That is exactly what I was looking for. I will dig more into eclipsec, but at a first glance, I think it would allow me to automate the initial setup of the project for other devs, including the product discovery paths. Thanks!