• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 478 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.

MCU-PLUS-SDK-AM243X: CCS: Changing path of SDK in linux command line compilation

Adan Flores
Prodigy 40 points
Part Number: MCU-PLUS-SDK-AM243X


Hello,

I am trying to figure out how to specify the path for an SDK that was rebuilt and moved from one computer to another in Linux command line build. I see on the documentation that this is the command to use:

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

so for me to specify another path, will I have to add it in place of <path1>? 

What if this line is already called with the paths from the original installation? Can I run any other commands to remove/override the original path?

Regards,

Adan Flores

  • 0
    TI__Guru**** 474421 points

    Hello,

    Adan Flores said:
    so for me to specify another path, will I have to add it in place of <path1>? 

    yes to specify a new path, what you mention above is correct

    Adan Flores said:
    What if this line is already called with the paths from the original installation? Can I run any other commands to remove/override the original path?

    It is not an issue to have multiple discovery paths set. It would only be an issue if you have multiple copies of the same version of the SDK of which some were modified.

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 40 points

    Hi Ki,

    Thank you for the feedback. What if we have an installation for the out of the box SDK 8.6 and we have a modified version as well? is there anything we can modify to make it different? maybe a minor release number?

    Ki said:
    It is not an issue to have multiple discovery paths set. It would only be an issue if you have multiple copies of the same version of the SDK of which some were modified.

    Lets say we have SDK 8.6 and SDK 8.5 installed. How can we select which one to use if we have both in the discovery path?

    Lastly, my issue is that DevOps already runs the command while setting up the environment and I can't modify this command. Is it possible to run it a second time with another path?

    Thanks,

    Adan Flores

  • +1 in reply to Adan Flores
    TI__Guru**** 474421 points
    Adan Flores said:
    What if we have an installation for the out of the box SDK 8.6 and we have a modified version as well? is there anything we can modify to make it different? maybe a minor release number?

    While I don't recommend it, you can modify the version numbers in the metadata - specifically .metadata/product.json and .metadata/.tirex/package.tirex.json

    I think CCS can only differentiate up to a certain amount. For example if the version number is 8.5.0.24, it would only use 8.5.0. So you would have to use a new version like 8.5.1.xx (instead of 8.5.0.xx)

    Again I rather you not mess around with the version numbers on your own but that is your call.

    Adan Flores said:
    Lets say we have SDK 8.6 and SDK 8.5 installed. How can we select which one to use if we have both in the discovery path?

    You would need to specify this in your project. 

    Adan Flores said:
    Lastly, my issue is that DevOps already runs the command while setting up the environment and I can't modify this command. Is it possible to run it a second time with another path?

    Yes. Running it each time would just append a another path to the discovery list.

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 40 points

    Hi Ki,

    Ki said:
    While I don't recommend it, you can modify the version numbers in the metadata - specifically .metadata/product.json and .metadata/.tirex/package.tirex.json

    We agree that this is not an ideal solution, but for now we will go with this while we find a more optimal solution.

    Thank you for your feedback. This issue is now solved.