CCS: Error #1965 on #include of header file from neighboring example project

Ralph Guditz

Tool/software: Code Composer Studio

I'm hacking at a copy of the power_measurement example project in my workspace under CCS v6.2.00050.

I'm have bma222drv.h "linked" into my project. Examination of Properties for the file show the link to be correct.

I get a red "X" (with rollover showing "#1965 cannot open source file "bma222drv.h" from CCS.

I have seen others posts which seem to say that I need to specify the oob project location for including files. I don't want to do that, since I don't want the compiler rummaging around there looking for things I may have forgotten.

Since CCS and the compiler have clearly correctly resolved my link to bma222drv.h in the oob project (see screenshots) and file is there (I can clink on the link and it opens), what's the problem?

Compiler can't find linked header file - Code Composer Studio forum - Code Composer Studio™︎ - TI E2E...

e2e.ti.com

I have added a "link" to the library header file that I want to use in my project. But CCS4 can't seem to find the "linked" .h file. The only way CCS4 can see the

over 8 years ago

0 JohnS over 8 years ago

TI__Guru**** 161575 points

Ralph,

You still need to provide the path to the file to the compiler via the project properties. The way you have it the editor/ide can find the file but the compiler also needs that information. The compiler only finds files based on the include paths specified and the #include statements However I can understand what you are trying to avoid. An option would be to change the #include where you reference the file to have some relative path information.

#include <oldproject/inc/john.h>

then in my search paths I have specified
"${WORKSPACE_LOC}"

This way when looking for john.h the compiler will append oldproject/inc and thus finds it in the other project in my workspace but won't find other header files in it.

Regards,
John

0 Ralph Guditz over 8 years ago in reply to JohnS

Intellectual 785 points

John,

So what stops the compiler from seeing $(WORKSPACE_LOC} and looking in *all* projects when it needs something. Does it only look in the tree "nodes" specified, and not below those points?

Assuming the above, it seems that you are basically saying that the compiler can't follow file links? Why not?

As the author of this post:
e2e.ti.com/.../53768

commented 6-1/2 years ago on what appears to be the same issue:

"Just seems logical that adding a link to the .h file in the project root should to the trick. CCS4 seems to be full of these little "illogical behaviours."

File Explorer doesn't show anything named "bma222drv.h" in the project directory, so I presume that links aren't represented as any sort of distinct file system construct. That might explain why the compiler can't follow links, unless perhaps the compiler were enhanced to look wherever/however links are stored. Out of curiosity, where are links stored?

I think it might be safer for me to COPY files like this to which I really just want to just link, but warn myself not to edit them by appending "_PseudoLink_to_Example_Project_oob--DoNotEdit" to their names.

All this seems quite illogical. Am I missing something?

0 JohnS over 8 years ago in reply to Ralph Guditz

TI__Guru**** 161575 points

Ralph,

Compilers do not search below the include paths specified. This is standard behavior for compilers. I suppose someone could implement one that searched sub-directories but that would lead to many cases of inconsistent results and have significant performance issues.

When you add a "linked" file it just adds an entry in one of the project files that specifies that the file is linked, there won't be any file in your project directory. Part of what confuses people is that it seems different for C files and .H files. That is because .C files are input files. The IDE gathers up the input files and passes them to the compiler. The header files do not get passed to the compiler, the compiler looks for them during compilation when it encounters a #include statement in an input file. When it looks for them it uses the information in the #include statement ("" or <> and any path info) and the include search path.

If you have a set of input files that are shared across projects you could put them in a common folder and then search the search path of each project to point to that.

The other thing to do is manage the search path order. The compiler will use the first file it finds on the search path. For example if you have a file.h in a /inc folder in your project and another file.h in a common header file folder just make sure the path to your projects /inc folder is listed above the common one and then the compiler will use the one in the project and only if it can't find one there will it use the one from the common folder.

One thing that would make it easier is if when linking a .h file the path to that file got automatically added to the search path. I can file a request for that. I am not sure if we have the ability to change it or not but it is worth checking.

Regards,

John