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.

LAUNCHXL-F280049C: CCS Index mixes projects includes, #if excludes warnings

Guru 55663 points
Part Number: LAUNCHXL-F280049C

Hello,

Affects all C2000 v22.6.0.LTS compilers and CCS 12.2 IDE.

Odd issues between two projects somehow being linked by the index to one another, no project dependencies other than virtual links to c:\ti folders. Configuring project specific index options in both projects, make change in one affects the other and index still points to a different include header file with the same name but of the opposite project in the tree. The header files are internally different, yet the IDE insists on keeping the index of the last opened project include paths even after forced rebuild. How can all that be stopped? 

Also #if #endif defines are highlighted over in the project header; compiler still executes the section for syntax etc., then warns of redefines above the lower section. Yet the compiler should not even touch highlighted sections. Such craziness has been noticed even in code analysis flagging Red errors inside #if / #endif sections that are clearly highlighted, these are do not touch sections. Also noticed some TI projects with header files defined as C modules even after the #ifndef H defines. Though removing the C defines does not correct the indexer mixing several projects virtually linked files to the same name. Long as you don't open a higher project up the tree all is good but if you do then bam broken links all over the place in the lower project down the tree.

Are these issues fixed in later versions of CCS and if so what versions fix them?

  • Odd issues between two projects somehow being linked by the index to one another,

    That was occurring since the lower project in the tree did not have a virtual link to the same header file name but in another SDK version folder. The IDE or indexer was incorrectly searching up the project tree for the file rather than the project include path to newer version of the SDK with the same file name. Adding the virtual file name to the project folder stopped that very bad behavior.

    The second issue of #if #endif with #defines are showing through highlighted pink section, commenting #defines stops compiler warnings. Though don't recall ever seeing the #define show through the highlight. However the compiler seems to still assemble the pink area, often produces errors if any exist.

      

  • Hello,

    There are various known issues with the indexer so the issues you describe does not surprise me. However:

    Are these issues fixed in later versions of CCS and if so what versions fix them?

    The indexer (as i'm sure you are aware of) is something that we have picked up from the Eclipse/CDT components that CCS leverages. We do not own or maintain them. We would reply on the Eclipse/CDT community to fix such issues. To be fully transparent, we are moving off this current dated Eclipse framework in favor of the new Theia IDE based environment. Major updates of the current CCS Eclipse based environment will slow down while the CCS Theia based environment will be prioritized.

    ki

  • Hi Ki,

    The IDE or indexer was incorrectly searching up the project tree for the file rather than the project include path to newer version of the SDK with the same file name. Adding the virtual file name to the project folder stopped that very bad behavior.

    Is there a CCS profile setting can stop indexer from searching other projects for the same file name? Yet the project has CDT build settings folder paths to the file being referenced. The indexer also gets stuck randomly on projects in the tree, after opening CCS after many projects imported into project tree. That occurs even with -clean and crash debug reports hang coincide with TI cloud agent executing several MsEdge tasks even when not opening any cloud functions. When forcing MsEdge task tree to end numerous unwanted (not instructed by user to launch any agent) these tasks keep trying to respawn until ending them one by one crashes Cloud Agent. When I see that many internet browser tasks and MsEdge is closed, a virus alert seems inevitable.

    BTW: CCS installer needs to ask permission, identify friendly name of the module requesting internet tasks to create an I/O rule in the firewall during the installation of the IDE. There are several popup messages for odd named modules without identity security certificate asking to have internet access. Not one popup that I recall ever identified name TICloudAgent will use MsEdge OS default browser for internet access. The default REX browser uses CCS Chrome so that is a curve ball for sure.