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.
Tool/software: Code Composer Studio
I just updated to CCS 8.2, and it no longer seems to respect the resource configuration setting. We have a project where based on the build config, we use different main.cc files. In a config where the main.cc file from the project's root directory is ignored, I still see CCS attempt to build it in the build log, which ends up doubly-defining many items:
Building file: "../main.cc" Invoking: ARM Compiler
This completely breaks things for us. It happens on both macOS and Linux.
Kaveh Vaghefi said:In a config where the main.cc file from the project's root directory is ignored, I still see CCS attempt to build it in the build log, which ends up doubly-defining many items
Could you send us a test project that demonstrates this as I have been unable to reproduces this so far.
Also for some background information, are you importing a project created with an older CCS into CCS 8.2, or opening an older workspace using CCS 8.2?
Yes, I'm upgrading to 8.2 and attempting to build an existing project. I'd recommend creating a project with the following hierarchy:
/main.cc
/foo/main.cc
Then exclude /main.cc from your build and attempt to build it. Inspect the output and you'll see it attempting to build the wrong main.cc. I can't send you my full project, and attempting to create a test project to reproduce it is work I don't have time for right now. This doesn't happen in 8.1, only 8.2.
I tried but unfortunately I have not been able to reproduce this on a simple project that I created using the above structure. I created a project with two build configurations (Debug and Release) - Debug includes the main.cc in the root directory and excludes foo/main.cc, while Release excludes the root main.cc and includes foo/main.cc. When I build it, the expected source file is built and the expected one is excluded.
Output of the Debug build:
Output of the Release build:
There must be some specific project setting or configuration that triggers the issue in your environment, which is why it would be very helpful if you could send us a reproducible test case.
Kaveh Vaghefi said:Would it be possible to show you what's happening over webex?
Sure, we could do that.
I would still need a reproducible test case to file a bug report for analysis, but perhaps the webex will help with getting there.
Let me connect with you offline about the webex details.
This issue is still not reproducible at TI. We are trying to figure out offline if there are other ways to recreate this. We will close this thread for now since there isn't immediate action/follow-up to report, but will come back and post any updates as they happen.