• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 56 subscribers
  • Views 1338 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

"Using Linked Variables in #include Search Path" appears not to work as advertised in CCS 4.2.5.00005- what do I do?

Bruce Bassett
Intellectual 720 points

In the page http://processors.wiki.ti.com/index.php/Portable_Projects_in_CCSv4_for_C2000 's description of a somewhat involved method of circumventing Eclipse's inability to deal with relative pathnames, there is a section entitled "Using Linked Variables in #include Search Path" whose procedure I have attempted to follow:

1) As it describes, I add linked resources SOURCE_ROOT and TIDCS_C2802x_INC to my project.  Note that the Enable linked resources box is checked:

2) I update the include paths in the project properties to use the new linked resources, using the ${ } macro expansion syntax it describes, which is matched by that for the predefined CG_TOL_ROOT:

3) However, when I do the build the files in these directories are not foung, and it appears that the linked resources did not get macro-expanded at all as shown in the highlighted text below which appears in the Console window.  This remains the case even after exiting and relaunching CCS 4.2.5.00005, and even after reboot.  I am also puzzled by the expansion that did succeed, since C:/Program Files/Texas Instruments/ccsv4/tools/compiler/c2000 is defined to be CCS_C2000_6_0_1_CG_ROOT rather than CG_TOOL_ROOT as shown above, although they are clearly related.

The failing #include file is #include'd by a version of DSP2802x_Device.h residing in the project directory which I modified to accommodate local typedefs.

**** Build of configuration Debug for project Piccolo27HwImpl ****

C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake -k all

'Building file: C:/Products/bassettb_IFOURXX_4/ifx_Controller/Code/ControllerProcessor/Piccolo/PicUart.cpp.c'

'Invoking: Compiler'

"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/c2000/bin/cl2000" -v28 -mt -ml -g --include_path="C:/Program Files/Texas Instruments/ccsv4/tools/compiler/c2000/include" --include_path="/include" --include_path="/HAL" --include_path="/Application" --diag_warning=225 --preproc_with_compile --preproc_dependency="PicUart.cpp.pp" "C:/Products/bassettb_IFOURXX_4/ifx_Controller/Code/ControllerProcessor/Piccolo/PicUart.cpp.c"

"C:\Products\bassettb_IFOURXX_4\ifx_Controller\Code\ControllerProcessor\Piccolo\Modified_DSP2802x_Device.h", line 132: fatal error: could not open source file "DSP2802x_Adc.h"

1 fatal error detected in the compilation of "C:/Products/bassettb_IFOURXX_4/ifx_Controller/Code/ControllerProcessor/Piccolo/PicUart.cpp.c".

Compilation terminated.

>> Compilation failure

gmake: *** [PicUart.cpp.obj] Error 1

gmake: Target `all' not remade because of errors.

Build complete for project Piccolo27HwImpl

I'm sure that I am missing something simple. 

Also, if anyone could explain why Eclipse can't support relative pathnames to begin with I would feel better about this state of affairs.

Thanks,

Bruce Bassett

Cummins-Allison Corp.

 

  • 0
    TI__Expert 3550 points

    Bruce,

    CCS does support relative path names, it requires you to change the .project and macro.ini files as listed in http://processors.wiki.ti.com/index.php/Portable_Projects_in_CCSv4_for_C2000. The files linked to the project can be relative to the location of the project, or relative to the location of an absolute path.

    Are you using the macros.ini file?

    Before you compile the project, do the folders ../DSP2802x_headers/include, ../ControllerProcessor/Hal and ../ControllerProcessor/Application appear under your C/C++ Projects Tab -> Piccolo27HwImpl-> include ? If they do appear, you should be able to see the files inside each document.

    - Erick

  • 0 in reply to Erick Macias
    Intellectual 720 points

    Erick-

    Thanks for getting back to me.

    Yes, I am familiar with it as that is the page I referenced in my post.  I am not (yet) using relative pathnames or macros.ini but am proceeding exactly as discussed in the section " Using Linked Variables in #include Search Path".  As it describes, I am using absolute pathnames from a linked variable, which seems like it should should work just fine without the not-yet-discussed-on-that-page-yet macros.ini. I look forward to using this more advanced feature of the tool after I can get the basic one working.  Sorry if I was not clear.

    In response to your other question, the include directories appear, but exactly as they do in the command line in the Console window, i.e. without the benefit of the symbol expansion, as you can see below.  The statement "To use the linked variable in a project as part of the #include file directory search path, simply surround the linked variable with curly brackets and add a “$” in front."in that section of the page seems not to be operative, since that's what appears in the Project Properties' Tool Settings tab under C2000 Compiler. Include Options as shown in my original post, matching the example of CG_TOOL_ROOT.  What am I missing here?

    Bruce

  • 0 in reply to Bruce Bassett
    TI__Guru**** 173310 points

    Bruce,

    If you want to use macros to specify compiler include paths you would need to create a build macro (similar to the linked resource macro you created above). This macro needs to be defined under Window->Preferences->C/C++->Managed Build, Macros tab. You can go in here and create a build macro with the same name as your linked resource macro, and then it should resolve correctly in the compiler include path.

    The wiki page you were looking at is not quite clear in this respect because it is written with the assumption that a user will also be creating a macros.ini file to make the project portable. If the macro is added to a macros.ini file then during import that macro will be resolved as both a linked resource variable as well as a build variable. However, if you are manually creating the project and haven't yet created the macros.ini,  then you would need to define the macro as a build macro in order to use it the compiler include path.

    Please take a look at this wiki article, it explains it better: http://processors.wiki.ti.com/index.php/Portable_Projects#Specifying_compiler.2Flinker_options

    Hope this helps.

  • 0 in reply to AartiG
    Intellectual 720 points

    Thanks Aarti- my include files are found now.  Presumably there are two mechanisms because build macros predates the linked resource mechanism?  Is the underlying difference one of evaluation time?

    Also, I'm still curious as to why the linked resource mechanism is necesssary, i.e. why doesn't Eclipse support relative pathnames to begin with?  Since it is open source it seems like it would have been better just to fix it there.  Is there some insight you can offer that will help me better understand such matters in the future?  I'm always happy to learn more about what's under the hood of the compiler.

    Thanks again,

    Bruce

  • 0 in reply to Bruce Bassett
    TI__Guru**** 173310 points

    Bruce,

    Glad to hear the include files are found and things are resolved there.

    The build macros and linked resource macros are really used for different purposes. Build macros are to specify paths in build time options (compiler/linker options), while linked resource macros are to specify paths to source files in the project. When creating a portable project that will be shared among several users, typically the macros are defined in a macros.ini file (with paths relative to project) and then during import, it will populate/resolve those macros under linked resource variables and build varibles.

    When you typically add or link a source file to a Ecipse project, the path to the file is resolved as a absolute path. This does not make it portable, hence the linked resource mechanism is required as the software may be installed in different paths on different users' machines.

    There is some general Eclipse and CCS specific information on the CCSv4 wiki page which you can browse through that might be helpful as well.