• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 340 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.

Original question:

CCS/TMS320F28377D: CCS/Eclipse unnecessarily changing project files

CCS/MSP432E401Y: Code Composer Studio cluttering up project files with changes when nothing apparent has been done to warrant the changes

Paul Hooper
Intellectual 525 points

Part Number: MSP432E401Y

Tool/software: Code Composer Studio

CCS often makes changes to the project file that don’t seem related to anything we are doing.  Below I have attached a snippet of an example.

What purpose do these numbers (that look like timestamps) serve that are tacked on all over the place?  When we do make changes to a project file it is hard to tell what changed because of the multitude of these types of entries.  There are also numerous other types of changes made by CCS.  Sometimes, I will make one simple change to a project, and it will cause a whole boatload of entries to be changed.  It makes it very difficult to control the projects. 

This question is closely related to 

https://e2e.ti.com/support/tools/ccs/f/81/t/755880?tisearch=e2e-quicksearch&keymatch=project%20files%20changes

Thank you.

Paul

 

  • 0
    TI__Guru**** 173310 points

    Paul,

    Please see these related threads that explain what these numbers are. For your purposes, you should be fine ignoring any changes to these build-flag ID numbers.

    https://e2e.ti.com/support/tools/ccs/f/81/p/528910/1924331#1924331

    https://e2e.ti.com/support/tools/ccs/f/81/p/440065/1579848#1579848

  • 0 in reply to AartiG
    Intellectual 525 points

    Thank you AartiG.

    In one of the links you cite, it is said

    The random number suffixes, that you're referring to, are not versions.  They're just meant to ensure that each build-flag setting has a unique ID within the scope of the .cproject file and its super-class hierarchy.  


    1/ If this is the case, why do these IDs need to change?  I can revert the changes, and I am able to build a binary that runs just like it would with the new IDs.  It seems that they are needlessly being changed.

    2/ You say that I can ignore the changes, but this is exactly the issue.  They are very hard to ignore.  I can make a change to the project, and when I look a the diff, my change is buried in a sea of unrelated changes which do not appear to be necessary.  This makes controlling a project a real pain.  If I can ignore these changes, why can't I just turn the "feature" off?

    3/ As I indicated before, these changes to the IDs are not the only changes.  The thread I referred to earlier describes other changes that take place.  It's as though CCS could care less about the developer and is going to do whatever it feels like doing.  Often times it has done the wrong thing and broken the build.

    4/ What triggers these changes to occur?  Perhaps if we understand this well, we can find a way to avoid workflows that trigger the changes.


    Bottom line:  It is really frustrating trying to manage a project which is being significantly changed for seemingly unnecessary reasons.  It would be nice if there was some way to eliminate the unnecessary changes.  These changes to IDs and other items are meaningless to us as developers, and we don't want to waste energy reviewing them all the time to make sure they are not hiding something that does matter to us.  

  • 0 in reply to Paul Hooper
    Intellectual 525 points

    Just received some additional feedback about this from our local TI FAE.  Looks like this is behavior that is common to all of Eclipse based tools, and there is not much TI can do about it.  Projects are managed by the CDT standard Eclipse plugin.

    If one is willing to move away from Eclipse managed projects, TI fully supports Simplelink SDK builds using IAR or managing ones own Makefiles.

    Bottom line:  There does not appear to be a way to work around this within the Eclipse environment.