Tool/software:
When sharing, exporting, or migrating CCS projects there may be issues with building the same project due to paths being incorrect.
The error below is an example
or the following
Tool/software:
When sharing, exporting, or migrating CCS projects there may be issues with building the same project due to paths being incorrect.
The error below is an example
or the following
gmake: Target 'all' not remade because of errors. C/C++ Problem gmake: *** No rule to make target 'C:/ti/ccs1260/ccs/eclipse/driverlib/f28003x/driverlib/ccs/Debug/driverlib.lib', needed by 'all'. C/C++ Problem gmake: *** [build-370047775] Error 1
These path issues are due to the fact that when migrating from C2000WARE 5.1.0 to 5.2.0.
These system variables are generated by CCS. However, the name of the variable is based on the ID of the SDK package.
The ID in the SDK changed between C2000Ware 5.1.0 and 5.2.0.
Hence the existence of this variable will depend on if the project is using 5.1.0 or 5.2.0.
If using SDK 5.1.0. This variable will exist in CCS. If using 5.2.0, it will not. The equivalent variable in 5.2.0 is COM_TI_C2000WARE_INSTALL_DIR. This is what needs to be used if SDK 5.2.0 is used.
Hence if a person is using a project based on SDK 5.1.0 and explicitly uses COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR in their project and then gives the project to someone who only has SDK 5.2.0, that project will automatically use 5.2.0 and then that variable will no longer exist in their environment since it is a 5.1.0 (and before) variable. Hence, this would cause variable build issues.
You can check the system variables by going to the project properties. Note: There may be other variables impacted as well
C2000WARE5.01 vs C20000WARE5.02
This issue is independent from the CCS version. Yes, CCS generates and populates the variable. But the name it generates and what it populates it with is all dependent on the C2000Ware package ID. For example, the install dir variable will be: COM_TI_<ID>_INSTALL_DIR.