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.
Good Morning,
I am resending this post because the answer I got the last time handled a CMD file issue and actually didn't answer the base question posed below. I am working with several people now and this issue keeps coming up. There must be a way to force all the underlying C source files to be transferred into the workspace locally, so that changes to them will not ruin the files in the ControlSuite directories. The only thing I have been able to accomplish at this point is to individually bring in source files in using manual copies, which is very tedious. Has anyone been able to get by this problem? See the following question description of the problem.
I have imported about 15 different projects over the past several weeks and have worked with and modified them to learn how to use the peripherals on my M36 Concerto part. I found out that the imports do not actually copy the files to my workspace, but link to the original ControlSuite directories. As a result I don't have any of the original projects in untouched form! I did the copy all option when I did the Imports, but I am positive the files aren't copied because I tested it this morning. I will now have to reload controlsuite files somewhere to get the original files back. However I can't put them in the default location because it will destroy all the work I have done these past weeks.
I need to know how to put ALL the project files into my new workspace so I don't have any links to the ControlSuite copies I referenced. I have looked through the documentation and have not been able to find a way to do it. Does anyone know how I can get all the project files in the workspace with no files having the linked file property?
Sincerely,
Mike Fontes
Hi Mike,
Mike Fontes said:I have imported about 15 different projects over the past several weeks and have worked with and modified them to learn how to use the peripherals on my M36 Concerto part. I found out that the imports do not actually copy the files to my workspace, but link to the original ControlSuite directories. As a result I don't have any of the original projects in untouched form! I did the copy all option when I did the Imports, but I am positive the files aren't copied because I tested it this morning.
The issue is that the most of the source files for the projects in the controlSUITE examples do not actually exist in the project folder but are linked to it via path variables. This is how they designed their projects. The "copy files to workspace" would apply to any files that are stored inside the project folder. Those files are copied over into the workspace folder. But any of the linked files that are outside the project folder via path variable will remain in place (this is so the project itself is portable).
If you wish to preserve the original controlSUITE files, I suggest copying the controlSUITE directory to another so you have a backup. Or you can change the path variable root location so that it uses a copy of the files that you do not mind modifying.
Thanks
ki
Ki,
The reason I have brought this up is that providing the links as you do is fodder for destruction of the library sources. It is the logical prerogative of engineers to go into a project and play with different files to begin to understand the inner workings of the processor. I have worked with many other environments and this is the first where the files shown in the project folder in the workspace are not separate entities from the distribution code.
I think there should be at least a visual cue to show which files are unique and which are libs. Better yet would be a copy option that was named correctly, which actually copied all the sources to the workspace folder so there would not be the chance of ruining the distribution code. The Copy all files button now does not copy anything but the one or two c files from the Controlsuite example, and leaves links that allow changes to all the lib files. That is a poor way to handle the file system. It is very bad when the user figures it out after loading and changing multiple files in multiple projects, and then finds that they are all broken!
There have been multiple posts from a number of engineers regarding this arrangement. I would think it should serve as a message to the team that things would be better if the methodology was improved.
Sincerely,
Mike Fontes
Mike Fontes said:The reason I have brought this up is that providing the links as you do is fodder for destruction of the library sources.
The controlSUITE examples do not come from the CCS team. However, that type of example (using references to source files instead of actually adding it to the project) is a common one which helps with project portability. The issue is that many source files are shared among various example projects and library projects. I tend to just back up the source files. It's something that I have always done in CCS and when using other environments.
Mike Fontes said:I think there should be at least a visual cue to show which files are unique and which are libs.
Linked files are identified by the little icon of a 'chain link' (or is it an arrow?) in the lower right corner of the icon of the source file.
Mike Fontes said:I think there should be at least a visual cue to show which files are unique and which are libs. Better yet would be a copy option that was named correctly, which actually copied all the sources to the workspace folder so there would not be the chance of ruining the distribution code. The Copy all files button now does not copy anything but the one or two c files from the Controlsuite example, and leaves links that allow changes to all the lib files. That is a poor way to handle the file system. It is very bad when the user figures it out after loading and changing multiple files in multiple projects, and then finds that they are all broken!
Eclipse/CDT sees files that are linked and files that are physically in the folder as two different things. Files physically in the folder are source files that have been added to the project. Linked files are just that - the project only keeps a reference to the file. So the reference is part of the project, not the file itself. Now I admit that to the user, they will not care if a file is physically inside the folder or if there is just a reference - both are to be compiled and resulting object files to be linked by the linker. But CCS is leveraging Eclipse/CDT and this is what was inherited. Your suggestion certainly makes more sense and is worth investigating.