• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 770 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler/TMS320C6678: Include files relative to current file being compiled

Carel Combrink
Prodigy 40 points
Part Number: TMS320C6678

Tool/software: TI C/C++ Compiler

Hi,

I am having issues including a file relative to the current file that is being compiled.

Say I have the following files in the given folders

  • TopFolder
    • SubFolder
      • Header.h
    • File.cpp


And in File.cpp have the following include:

#include "./SubFolder/Header.h"

The above does not compile unless I add TopFolder to the includepath of the compiler. 

Is there a way to allow the compiler to find the include file relative to itself or will it only work when the includepath is set up as mention. 

Using the following:

  • Code Composer Studio: 7.2.0
  • board: TMS320C6678
  • Compiler: ti-rtos C6000_8.2.2 

  • 0
    TI__Guru**** 244930 points

    Unfortunately, I am unable to reproduce the problem.  Please package the problem project as described in the article Project Sharing.  Then attach the resulting zip file to your next post.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 40 points
    Unfortunately I am not able to share the code, as it is part of a large codebase.

    Do I understand correctly that the compiler is supposed to be able to include files relative to the current one getting compiled ,even if the current file is not in the include path?

    Is there some setting that would influence this?
    Or any other known thing (that might be wrong) that might influence this?
  • 0 in reply to Carel Combrink
    TI__Guru**** 244930 points

    To understand how the compiler searches for include files, please see the section titled The Search Path for #include Files in the C6000 compiler manual.  In this particular case, the path ./SubFolder/Header.h is evaluated in the context where TopFolder is the current directory.  That is because the file currently being compiled, File.cpp, is in the directory TopFolder.  Please be sure these same circumstances are present in your larger CCS project build.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 40 points

    Is it possible that there is a limit in the path to search for?
    For example, say "File1.h" includes "/long/path/to/file.h" which includes "another/long/path/anotherFile.h" which includes "some/other/long/path/to/some/otherFile.h"

    From the error output the error states: 

    Description Resource Path
    #1965 cannot open source file "../../../Headers/to/file.h"  file.hpp /otherpath/library/Include/library/folder

    And all of the above paths looks correct, and can be manually found using the file explorer. But yet the compiler fails to open the file. 

    In the compile output for one of the failed files the line "C:\XXX\YY line X: fatal error # 1965" have about 20 directory changes ("\"-char) and have more than 200 chars based on a quick estimation.

    Might this be the reason why the compiler can not open the file?

  • 0 in reply to Carel Combrink
    TI__Guru**** 244930 points

    I am not sure what is happening.  One guess is that you have exceeded the Windows limit on the length of a directory path.

    It is understandable to think that, since a file really is present on the system, then the path to it must be within the limit.  But as files include yet other files multiple times over, the compiler can end up constructing a path that looks like ...

    ../../path/to/first/dir/../../../path/to/second/dir/../../../../and/so/on

    When that finally gets passed to fopen, it fails not because the file isn't present, but because the path is too long.

    I searched on this topic and found this page from Microsoft.  It says the maximum path length is 260 characters.  However, there are some methods shown for overcoming this limit.  I don't know if these methods will solve your problem.  But I think it is worth the attempt.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 40 points

    It appears that the issue was the path length was too long for system to handle. 

    We have reworked our library to fix the includes and it seems like it is working now. 

    Many of our files included files close to it, through long indirect paths. This was cleaned up and files were moved closer to each other. 

    Thanks for the assistance.