LAUNCHXL-F280039C: Build error gmake: No rule to make target 'C:

John Tsinetakes1 said:

gmake: *** No rule to make target 'C:/ti/ccs1260/ccs/eclipse/driverlib/f28003x/driverlib/ccs/Debug/driverlib.lib', needed by 'all'.                    C/C++ Problem

First can you close CCS, and re launch it in a new workspace then try rebuilding it?

If you see the same error please help answer the following questions. 

1. Can you compare the project properties of both projects and double check that the system variables are the same?

2. Is it pointing to the right C2000ware installation directory when trying to search for the driverlib/f28003x/driverlib/ccs/Debug/driverlib.lib? \

3. Is this driverlib.lib file already in the project, if so can you double check in the properties of this file where it is pointing to as reference?

Best,

Ryan Ma

"First can you close CCS, and re launch it in a new workspace then try rebuilding it?"

Tried a new workspace, same gmake build error in the new workspace.

"1. Can you compare the project properties of both projects and double check that the system variables are the same?"

Yes the the system variables are the same and all the search paths are the same. Search path screen shots attached

"2. Is it pointing to the right C2000ware installation directory when trying to search for the driverlib/f28003x/driverlib/ccs/Debug/driverlib.lib? \"

Yes

One person had C2000Ware_5_01_00_00 and the other C2000Ware_5_02_00_00.

But both people now have both C2000Ware version installed and we still get he same gmake build error.

"3. Is this driverlib.lib file already in the project, if so can you double check in the properties of this file where it is pointing to as reference?"

Yes the driverlib.lib file is already in this project see photo for location file is pointing to.

The build error is still:

***********************************************************************************************

gmake: *** No rule to make target 'C:/ti/ccs1260/ccs/eclipse/driverlib/f28003x/driverlib/ccs/Debug/driverlib.lib', needed by 'all'.
Invalid argument '-s': File "C:\.metadata\sdk.json" does not exist
gmake: *** [build-12007825] Error 1
gmake: Target 'all' not remade because of errors.

*************************************************************************************************

We cannot find what in hte project is asking for the location "C:/ti/ccs1260/ccs/eclipse/driverlib/f28003x/driverlib/ccs/Debug/driverlib.lib'"

Hi John,

John Tsinetakes1 said:

Yes the driverlib.lib file is already in this project see photo for location file is pointing to.

In this screenshot there are two variables that are different

COM_TI_C2000WAREINSTALL_DIR and the one being used in the "Location" field COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR

Can you update the "location" field with the COM_TI_C2000WAREINSTALL_DIR?

Changing in the  location field above to COM_TI_C2000WARE_INSTALL_DIR removed some of the errors but 2 error remain.

"syscfg" -s "/.metadata/sdk.json" -b "/boards/LAUNCHXL_F280039C" --compiler ccs
subdir_rules.mk:16: recipe for target 'build-12007825' failed
Invalid argument '-s': File "C:\.metadata\sdk.json" does not exist
gmake: *** [build-12007825] Error 1
gmake: Target 'all' not remade because of errors.

I found that in the Build Variables in the picture below there are still variables C2000WARE_DIR_ROOT and C2000WARE_ROOT that have a path defined with COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR.

I cannot figure out how to edit the paths for these two Variables.

You can also create the variable for COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR to be the same location as the COM_TI_C2000WARE_INSTALL_DIR.

Best,

Ryan Ma

I created another variable and some of the path errors went away but the project still has the build error shown in the attached screen shot

Hi John,

This is an error in the SysConfig path. In the project properties, for Build > SysConfig please make sure the correct variables are being used.

Best,

Ryan Ma

Hi Ryan and John 

Nice to meet you, I also come across the same issue in customer side. I think the err report are caused by Sysconfig, but still have no idea how to solve the issue.

MCU F28P559SJ9 SDK C2000Ware 5.2 Sysconfig 1.20. no SW version change during the development

customer can open the sysconfig file in stand alone sysconfig but cannot open that with the CCS integrated sysconfig, ccs will report: 

"C:\ti\C2000Ware_5_02_00_00\meadata\sdk.json does not exist".

the computer which can open the sysconfig file with the sysconfig in ccs do not report the compile fault.

Thanks

Joe

Hi all,

Joe Ji said:

"C:\ti\C2000Ware_5_02_00_00\meadata\sdk.json does not exist".

Does this path exist on the customer's filesystem, it appears misspelled and should be something like this: "C:\ti\C2000Ware_5_02_00_00\.metadata\sdk.json"

Best,

Ryan Ma

Hi Ryan

the 5.2 SDK version is installed in the default path: C:\ti\c2000\C2000Ware_5_02_00_00, so I think it can be the issue that ccs still try to find the sdk.json in the path without "c2000"

Thanks

Joe

Hi,

The expert is out of office today, please expect a response back by Monday.

Thank you,

Luke

Hi Luke

I solve this issue by change the SDK install path from C:\ti\c2000\C2000Ware_5_02_00_00 to C:\ti\C2000Ware_5_02_00_00, sysconfig and ccs build both can work well.

Thanks

Joe

Hi Joe,

I am glad to hear that you were able to find the correct path.

If you come across this issue again, and a way to replicate the finding I can file a CCS bug to figure out why this is occurring.

Apologize for any inconvenience this caused. 

Best,

Ryan Ma

I searched on the E2E for instructions on the preferred way to uninstall C2000Ware and I stumbled upon these two recent 2 months old posts that are directly related to my issue.

TMS320F28P550SJ: CCS 12.7 show different variables in different launches: COM_TI_C2000WARE_INSTALL_DIR & COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1358598/tms320f28p550sj-ccs-12-7-show-different-variables-in-different-launches-com_ti_c2000ware_install_dir-com_ti_c2000ware_software_package_install_dir

C2000WARE: Behavior of CCS with regard to COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1373420/c2000ware-behavior-of-ccs-with-regard-to-com_ti_c2000ware_software_package_install_dir/5247176?tisearch=e2e-sitesearch&keymatch=how%25252525252520to%25252525252520unintall%25252525252520c2000ware#5247176

From reading these two previous posts it appears the problem of CCS adding a variable COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR started in CCSv12.6, but the second post shows the same issue occurs in CCSv12.7

The post from CCSv12.6 says they have trouble importing a project from the GIT repository on two different machines both with CCSv12.6 on machine makes the variable, "COM_TI_C2000WARE_INSTALL_DIR " and another computer project import makes the other variable "COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR" one suggested remedy on this post was to move to the latest version of CCS but the second post I listed above shows CCSv12.7 manifests the same problem and it happens on the same computer intermittently depending on different times the CCS workspace is launched.

WE have found that two computers both with CCSv12.6 cannot share the same project between two different computers without the variable "COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR" showing up on one computer and the other computer has the variable "COM_TI_C2000WARE_INSTALL_DIR". We two other people imported the same project on their respective computers that had CCSv 2.5 installed the long variable "COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR" did not appear in the imported project and the project Built fine without gmake  errors.

So the question is, given this information above, what is the preferred remedy to this issue? 

Move back from CCSv12.6 to CCSv12.5?

Thanks

Hi John,

Thank you for the detailed steps. I will report this to our SDTO team to figure out what may are the best steps to avoid this issue completely.

Best,

Ryan Ma

I have more definitive information on the issue.

1. The issue is not when the project is imported to a different computer that the second computer is missing any TI applications or libraries. the issue is that new Path Variables are added to the imported project that are not defined. The worst one is ${COM_TI_C2000WARE_SOFTWARE_PACKAGE_INSTALL_DIR}. 

2. Adding these additional path variables to the project's Preferences  > Code Composer Studio > Variables doe snot fix the problem.

Unless I am adding the new variables incorrectly, can someone check the image below to see if I have added the new imported variables correctly?

3. The only way I found around the newly import variables issue is to go through every General, Build, and Linker path variables in the project's preferences and check if it is defined or not. If a variable is not defined the way to fix it is to delete the variable completely and just browse to and add the explicit path as shown in the image below. Before adding the explicit path there was and issue with Code Compose finding the root location of the C2000Ware installation folder because the path had an unrecognized variable in the path name.

4. The other issue that creates a problem is there is difference in the C2000Ware's installer depending on if the C2000Ware is installed  from the Resource Explorer inside CCS or directly from the TI website.

When installing from the Resource Explorer inside CCS the default location from the installer is C:\ti

When installing directly from the TI website the default location from the installer is C:\ti\C2000

5. The other issue is once this happens the many errors from the Linker may seem confusing because many of the errors make no sense and seem unrelated to the path variable issue, but as the path locations are one by one painstakingly corrected the errors go away and the ones that remain may make more sense.

Hi John,

The SDTO team is looking into this to see how they can fix this. I will keep you updated. 

Best,

Ryan Ma

Hi Ki,

Thank you for the detailed explanation. I can create a FAQ on this as it seems this is a common error that occurs when migrating or having two projects with different C2000WARE versions.

Best,

Ryan Ma

Yes, as we discussed offline, an FAQ would be good.

Some other key details we discussed that I want public for others:

- CCS version does not matter as the variable names are driven by the C2000Ware version being used.

- Other variables are impacted. Basically all variables that start with COM_TI_*

Examples: 

COM_TI_<ID>_INCLUDE_PATH

COM_TI_<ID>_INSTALL_DIR

COM_TI_<ID>_LIBRARIES

COM_TI_<ID>_LIBRARY_PATH

COM_TI_<ID>_SYMBOLS

COM_TI_<ID>_SYSCONFIG_MANIFEST

Not sure if there are others.

The other reason the problem occurs is if the different versions of C2000Ware are not installed such that CCS is recognizing them.

For example if a project was made in C2000Ware 5.1.0 and then imported to another computer that had both C2000Ware 5.2.0 and C2000Ware 5.1.0 installed, if CCS only sees C200Ware 5.2.0 then the generation of the different path variables occur. If the project made with C2000Ware 5.1.0 is imported to another computer and that computer has both C200Ware 5.2.0 and 5.1.0 installed and CCS properly recognizes both versions then no issue occurs with new path variables being made after the project is imported to another computer.

The two versions of C2000Ware need to show up as Discovered Products under Windows>Preferences>Code Composer Studio>Products.(Discovered Products)

It is possible to install an additional version of C2000Ware but it will not show up under Discovered Products in CCS.

Yes that is correct.

Also the starting point is to know which version of C200Ware was used when the project was first made.

Thanks

John Tsinetakes

Ryan Ma said:

What you're saying is that one way to avoid this problem would be to have both version of C2000WARE installed and making sure CCS is able to detect the two versions? 

Yes, this makes sense. By default, the project will try to find the "best match" when trying to resolve a project dependency. So if a project is configured to use SDK 5.1.0, it will always look for that version first and if it can't find it, it when then look for the next closest version - like 5.2.0 in this case. But if you have both version installed and detected, then the project will then use the exact match one first.

Note that there is a way to set the project to ENFORCE you to use the exact match only and it will give a warning (or maybe even error) if it can't find the exact version. This may be helpful here if you know your project MUST use a specific version of the SDK.

Hi John. I also want to address this comment about C2000Ware installs not showing up under CCS Discovered Products.

John Tsinetakes1 said:

It is possible to install an additional version of C2000Ware but it will not show up under Discovered Products in CCS.

There is a way to resolve this if it happens. Please see the section called "Product Discovery" at this link: dev.ti.com/.../node