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.

CCS/TMS320F28379D: gmake: *** No rule to make target '

Part Number: TMS320F28379D

Tool/software: Code Composer Studio

Greetings,

                 I am trying to build a project using CCS 8, and I’m getting the following error:

 gmake: *** No rule to make target '../<file_name.cpp>', needed by '<file_name>.obj'.

                 <file_name>.cpp is in the same folder with other files which are successfully built.  What causes this error, and how can I solve it?

 Thank you

Ed

  • Hi Ed,
    Is your project a standard CCS project? Can you create a test case (project + source file) and share it on this thread?

    Thanks
    ki
  • Hi Ki,

    Thanks for the quick reply.

    I'm not sure what you mean by a standard project. Our projects are straightforward, although large, CCS projects, drawing files from many different folders. We have many projects which are this way. Other projects, with which I am working, build with no issues. This is the only project which I have tried to build which does not. This is the only issue which is stopping it from succeeding.

    Ed
  • Hi Ed,

    There are 3 types of projects that can be used with CCS. A standard CCS project is what we recommended but people have decided to go with other options for various reasons.

    The error message you see is usually caused because it is unable to find the source file. I assume the source file in question is one level up from the configuration build folder? If so, then it is a mystery why gmake is unable to find it. A small, reproducible test case would be very helpful here in our analysis.

    Thanks

    ki

  • Hi Ki,

    We are using the default build command, and have it set to generate makefiles automatically.  Does this answer your question?

    I don't see the generated makefile in the project folder.  Would I find it somewhere else?

    The file which isn't building is in a completely different folder with several other files which are common to the various projects.  All the other files in the folder are seen by gmake and are building without errors.  So far, I am unable to reproduce this in any other project.

    Ed

  • Ed Sanders said:
    We are using the default build command, and have it set to generate makefiles automatically.  Does this answer your question?

    This is a managed makefile project. There are two kinds - CCS and standard Eclipse. The quickest way to tell between the two is to go look inside your project folder and see if the file ".ccsproject" exists. That would confirm if it is a CCS project.

    Ed Sanders said:
    I don't see the generated makefile in the project folder.  Would I find it somewhere else?

    It will be generated inside the the build configuration folder that resides inside the project folder. For example, if you are build the "Debug" configuration, the makefiles and the object files would be generated inside a "Debug" folder under the project folder

    Ed Sanders said:
    The file which isn't building is in a completely different folder with several other files which are common to the various projects.

    gmake is expecting the file to be up one level from the build configuration folder - ./<file_name.cpp>. This means the project folder. If it is in a different location, as you mentioned, then I'm not sure why the makefile is getting generated with the path as mentioned so. As mentioned, a test case would really be helpful here.

    Thanks

    ki

  • Hi Ki,

    I think we are a step closer!

    Yes, there is a ‘.ccsproject’ file. I also see a makefile in the Debug folder. And I also see the file mentioned. It does not have a folder preface, but all the other files in that folder are preceded with the folder name. I rebuilt the project to verify that this happens again, and it does.

    Below the Debug folder, there are other folders for the various things we are pulling into the project. The file of concern is in its appropriate folder in the built version. So I looked for evidence of the build of the file in the Build Console and found it.

    So I am suspecting that the lack of the folder preface which is in the makefile is preventing the linker from finding the .obj file. Does this make sense to you? What would cause this?

    Thank you,

    Ed
  • Hi Ki,

    The problem is solved! The Project Explorer window showed a ghost version of the file in the root of the project. The file is not in that folder, so when I double-clicked on it, CCS told me there was nothing there. So I deleted it from the project in Project Explorer, and now the project builds. Do you have any idea how the ghost file could have been put there?

    Thank you,

    Ed
  • Ed Sanders said:
    The Project Explorer window showed a ghost version of the file in the root of the project.

    I'm not sure what you mean by "ghost file". I'm guessing it is a broken link. Can you send a screenshot of the project explorer?

    Thanks

    ki

  • Hi Ki,

    Unfortunately, I've corrected the problem, and don't know how to get it back.  But the ghost file was a file which Project Explorer said existed at the root of the project as well as in its correct folder.  But, in reality, it did not exist in the root of the project, and only existed in the correct folder.  As noted above, when the makefile was generated, I observed that the correct filename was present.  But it was not prefixed with the correct folder as the other files in that folder were.  This was because I was looking at the line in the makefile which had been generated to cover the ghost file at the root of the project.  I believe that if I had looked further into the makefile, I would have seen the same file prefixed with the correct folder too.  This explains why I could see that the file had been compiled into object code.

    What I don't understand is how the ghost file at the root of the project got there.  You mentioned a broken link.  How could that occur?

    Thank you,

    Ed

  • A broken link would apply to a source file that was linked to the project and that that path used by the link is no longer valid (the file moved to a different location). A link can get broken if the path relies on a build variable and the value of that variable is no longer valid.

    ki

  • Hi Ki,

    Helpful link. Thank you!

    I was able to reproduce the issue by copying the file, which had originally caused the problem, to the root of the project, linking it to the project, and then deleting the file. When I built the project, the original issue occurred. I also realized that the compiler output produces the exact path where it believes the file should be. That can be used to help find the broken link, which I had been calling a ghost file. Deleting the link and re-building caused the project to build successfully.

    So all things are now understood. I can close this issue.

    I appreciate your help Ki,

    Ed