CCS/C2000-CGT: Multiple projects build issue

Shao Ma1 said:

subdir_rules.mk:16: warning: overriding recipe for target 'C:/xpath/Main/CCS3.1'    //Note: the last subfolder name "CCS3.1" is partially chopped off as it should be "CCS3.1 xyz" as complete.

Spaces in directory/path names is known to cause build problems. What is your CCSv10 workspace and project path? If it contains spaces I would recommend importing the project into a workspace path that does not contain any spaces. 

If that still does not resolve the issue please share your project with us so we can reproduce and investigate the error. If you do not wish to post the project here you can share it with me via private message. To send me a private message, hover over my E2E forum ID and select "Send a private message". You can zip up the project folder and attach the zip file to your message.

I also see that you have created another E2E post on the same topic of migration: https://e2e.ti.com/support/tools/ccs/f/81/t/917943 
Since that is just an update on the same issue, I ask that we continue the discussion in this thread so there is a single place to track the issue.Thank you!

It appeared that at the beginning of importing CCS 3.x project, CCS10 will use a source XP project path for this import and conversion and it even set it to "directory specifier" automatically before conversion would start. Since this XP path is not what I wanted, after I corrected it manually in "Directory Specifier" to point at the right path in Window 10, somehow it only seemed to have corrected on the surface as CCS 10 build still looks at the same uncorrected XP path hence causing build error #1. Additionally, this path name has a space inside the folder name string so it gets an build error for truncating it short as "deprecated syntax".

FYI, my CCS10 workspace path is different than XP project path. Are they supposed to be equal to resolve this issue?  BTW, it'd be really inflexible if I need to name source and target path same in order to resolve this.

Let me know if there's a way to fix this issue.  Thanks in advance.

Shao Ma1 said:

FYI, my CCS10 workspace path is different than XP project path. Are they supposed to be equal to resolve this issue?  BTW, it'd be really inflexible if I need to name source and target path same in order to resolve this.

No the CCSv10 workspace path does not need to be the same as CCS3.x project path. 

It is still difficult to provide a solution without looking at the project and circumstances causing the error. Can you share the project with me via private message?  

I understood CCSv10 workspace doesn't have to be the same as CCS3.x path per migration requirement in theory. But what I was asking is to assume if src and target path are made same just for this issue, the build would pick up the .OBJ correctly and hence would have worked. Additionally, if I remove any space in my path folder name, then I would also able to avoid this "deprecated syntax" during build and in theory, I'd be able to build my converted project successfully.

You can see clearly what I am doing is to figure out how to circumvent this issue while you are looking at how to fix it permanently for CCSv10. As for passing you project for debug this issue, I need to be careful not to disclose our source too much - my dilemma.  I will set up a same target folder as mentioned above to see if my build can succeed then I can use such evidence as proof of this failure. Will let you know.

Thanks for understanding.

Until today, I just realized, after didn't hear from your response, that my one reply dated yesterday afternoon (2:00ish) was not actually recorded in this thread (lost ?) and FYI I did saw it went in. That reply started with "Update" about my finding.

Here is little extra about my setup 

• Windows 10 enterprise 64-bit
• CCS 10.0.0.00010
• No specific device/board or debug probe were involved as this is a source code migration for CCS 10 from CCS 3.3.

Let me try it again here and this is a repeated update of my investigation dated on Jun 29th. What I did was to use the same directory path structure between migration source in XP and target path in Window 10 so I can prove if indeed the gmake and build failure due to unable to find .OBJ in its designated folder. Once I make src, target folder same, build worked.  Secondly, I also remove space in my imported XP source during conversion inside CCS 10.0. This helped me to rid of build "deprecated syntax" error. By this proof, I'd point the root cause for build inside CCS10.0 that failed to resolve imported src to work its workspace output folder, etc. 

Although this "happy path" arrangement of XP src matched that of CCS10 target path can allow build to pick up .OBJ correctly, it also point out that when src, target path, during migration, are unmatched, build would be still able to find the .OBJ and build successfully. Now, there's another issue emerged due to this "happy path" arrangement resulted in unmasking as below:

subdir_rules.mk:9: recipe for target ' …. ' failed due to fatal error #1965: can not open source file "std.h"

This "std.h" is referring to the location of include where my old DSP/BIOS (5.42) is located.  BTW, this build error only occur when building this compound project with two other lower level child project and this error points at building the child project.  But if I build the same project in standalone, the build just worked.

Due to sensitivity nature of disclosing any source, I'd like to propose a discussion on Zoom with screen shared to reveal enough info to help your debug. Please let me know promptly and thank you. 

I can't guarantee that the issue will be understood and resolved via a shared session but we can give it a try as a first step. TI recommends the use of Webex for such debug sessions.

Let me know what would be a good time for you in the early part of next week. I will contact you via private message with more details.

Shao,

Project migration issues (especially between wide version variations like v3.3 to v10) are not always completely smooth. The tool does attempt the migration to the best of its ability, but sometimes additional manual tweaks are necessary after the project migration. And in some cases (depending on complexity of project and its settings) it is just more efficient to create the project from scratch in CCSv10 rather than spend time debugging/fixing tool migration issues. 

Have you considered the option of creating them as new projects in CCSv10? Time spent on going down that path may be more fruitful than debugging 3.3->10 migration issues and waiting for potential bug fixes (if any were to be found). Moreover without a reproducible test case there is the additional challenge of understanding the issue and finding root cause via remote demo session.

Please let me know how you'd like to proceed.