• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 54 subscribers
  • Views 688 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.

how to create CCS projects with existed eclipse projects

Weichun Yuan
Expert 1210 points


We are trying to create a CCS V5.x project using direcotries/files which was used by some host projects which is built by other existing eclipse projects. The file structure is sketched as followings:

Now I have several questions

1. Where should I put my master CCS project? Under subrelease or under "dsp directory 1"?

2. If I put it under subrelease, how do I prevent it from colliding with existing eclipse projects? We know that the ccs project is recorded under .ccsproject, but how about .project, and in particular .config and .settings directory? Should I somehow change these default names or are there other ways for us to use CCS V5 without interfering with eclipes?

3. If we have a project in directory say, "subrelease/dsp directory 1", is there a way to include directory or files under "subrelease/shared directory 1/shared directory 21" without copying so that we can share the same files/directories between both host (build by host side eclipse tools) and dsp (ccs 5.x)? Is a sub-project within "subrelease/shared directory 1/shared directory 2" the only way, or best way to go?

4. what would be the best practice in planning for such cases -- we have a pretty big project/files.

thanks a lot

Weichun

               |-------- dsp directory 1

               |-------- dsp directory 2

               |-------- shared directory1

               |-------- shared directory2

                                                 |--- shared directory 21

                                                 |--- shared directory 22

subrelease --  

               |-------- host directory 1

               |-------- host directory 2

  • 0
    TI__Guru**** 171309 points

    Hi,

    Your question is very open and heavily dependent on the way you work. In this case, I can make a few comments / suggestions:

    1. The master CCS project can be located anywhere, since it can simply be imported to every workspace for every project (you can create multiple workspaces). Keep in mind that, when a project is imported to a workspace, it can either create an entire physical copy of it or simply a reference (link) to it. This selection is done when you import the project to a workspace (menu Project --> Import Existing CCE/CCS projects). Keep reading for additional suggestions on where or how to leave your master project.

    2. The best way to prevent this is to link a project to a workspace as mentioned above. This way no files/directories will clash.

    3. Source files can also be linked to any project, as well as libraries and include directories. Therefore, you can use the same physical source file across multiple subreleases (that keeps consistency across releases). However, including files across projects in a workspace can lead to problems during building and cross reference between projects. The most recommended way is to leave the shared source files, libraries and include directories in a common place and link them to all your projects. In your case, all the source files of the master CCS project would be directly linked to each of the subrelease projects. 

    4. As I mentioned before, there is not a single solution for this. However, interesting discussions about this problem are shown at this forum thread and this other one.

    You can also try to organize your projects in a similar way as shown in the Starterware - as you can see, there is a separation between the projects/source files for libraries, device drivers, utilities, applications, etc. That helps compartmentalize the multiple components used by each of your subreleases. 

    A concept that must be common to any strategy you adopt is to make these projects Portable - i.e., they don't depend on hardcoded links. This is also discussed in the forum threads above.

    As I mentioned initially, there is no correct answer, but instead a cloud of possibilities that will definitely help you maintain the project for the future. Therefore maybe someone else can also comment on their way of solving this same issue.

    Hope this helps,

    Rafael