Error processing changed links in project description file.

Kurt,

If you are going to use a source control system I would suggest installing the matching plug-in for it into CCS.  Instructions for a few of the common ones are available here: http://processors.wiki.ti.com/index.php/Category:CCS_Plugins

Working with source control also usually means making your projects portable, I think you may have another thread on this.  Note that it is a lot easier to make a project portable in v5 than in v4.  The relative link comment scares me a bit as you cannot do that for source file references, they are stored in the project files as absolute paths, but can be based on macros to make them portable.  Maybe you meant the -i paths.

CCSv5 also uses a much newer version of Eclipse which can make it easier to find the latest plugin for various version control vendors.

Is the problem you are hitting that CCS is trying to write to the .project file when building?  Archive a copy, check it out, then build, compare the resulting file with the original.  What was CCS trying to change.

John

yes, I have the TFS plugin in my copy of CCS4.  but, I think you do not understand what I am doing.

what we're talking here is continuous integration. here is the process in a nutshell:

1) check out some module for editing (using the TFS plugin)
2) make some changes. 
3) check in the changed module (again using the TFS plugin)
4) a build server detects the checkin and kicks off a changeset build
5) the changeset build extracts all of the current source from TFS to some build directory
6) make a new workspace directory in the build directory
7) using Code Composer terminal commands
    7a) import a unit test project from the build directory into the new workspace
    7b) build the imported unit test project
8) using Debug Server Scripting, run the unit test program in a simulator
9) analyze the output from the unit test program to verify that all tests pass
10) notify the build server of pass or fail

all of the files from step 5 are set to read-only.  this is standard source control technique.  files that have not changed are read-only. files that are checked out for change are set to writable. since we are doing a build we will not change any files - no file will be checked out or made writable. we just want to use whatever is the latest code.

when I import the unit test project in step 7a, CCS4 complains if the .project file is read-only. this goes against general source control usage.  the .project file should not have to be checked out or made writable. the import should work with read-only files. (that is unless you can describe another way for me to build and run the project in some other directory without user interaction.)

my project is portable.  that is why I import the project as part of the changeset build. it would be much more useful if the makefile could be generated without hard coded paths.  then I would not have to import into some dummy workspace.  then I could just run gmake. but the makefile as currently generated is full of hard coded paths. I do not want to tweak it by hand to be generic just to have to do it again when the project or dependencies change.

Kurt,

We are not going to get anywhere until we figure out why CCS is updating the .project file.  I have made a number of my projects read-only (except the debug folder) and I am able to import and build them without CCSv4.2.4 complaining about not being able to update the .project file.   I have tested with several types of projects and as long as they have been properly made portable I can import them into a new workspace, setup the linked resource paths in my workspace preferences and I can build them with all of the project files being read-only.

Can you send you .project file?  Preferably a version of it before 7a and one after 7a (after you have made it writable so we can see what CCS is trying to do to it).

Regards,

John

I thought that was obvious from the message, "Error processing changed links in project description file". 

because my project is portable, CCS4 is updating the "Resolved location" when I import the project. when the locations are resolved CCS4 is modifying the .project file to reflect the resolved location.  if I look at the file properties when .project is read-only, and I get the message, then the Location is "PYROCAMIV_PATH_VARIABLE/Chopper.c" for example and the "Resolved location" is "Unknown" if I look at the file properties when .project is writable then the "Resolved location" is assigned

to recreate the problem do the following:

1) create a new project
2) create a macros.ini file in the project folder
3) define some path variable in the macros.ini file
4) remove the project from the workspace
5) import the project
(the path variable in macros.ini is not effective until a project is imported)
6) add some new file based on the path variable
7) switch to another workspace
8) make the .project file read-only
9) import the project into the new workspace

Works fine for me.  I will create a video tomorrow.

John