• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 52 subscribers
  • Views 2016 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.

CCS/CCSTUDIO: Chained dependency order in Eclipse CDT

Keith Elliott
Intellectual 890 points
Part Number: CCSTUDIO
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

I'm attempting to utilize the "Project References" feature in Code Composer for an embedded firmware project. I'm using Code Composer Studio 7.0 which is essentially just a wrapper for Eclipse 4.6 with CDT 9.0 and JRE 8. However, from what I can tell the features I'm trying to use are specific to the CDT. The embedded firmware is broken up into several parts with a few libraries, an RTOS platform, and the "core" firmware.

The intention is that the dependencies of a project are automatically built and updated in the proper order whenever a build on the core firmware project is triggered. However, due to some libraries building upon others I'm seeing some weird behavior that i don't quite understand. The dependency graph is shown below.

enter image description here

As you can see, there's a maximum of four levels of dependency. The issue that I'm seeing is that, while I've ordered the references in the order "Properties->C/C++ General->Paths and Symbols->References" as [Platform, PAL, HAL, Features] for the firmware project, the build order doesn't seem to follow that specification. The ordering seems to be semi-random. After a clean sometimes the PAL will build first, other times the Features will. The entire build ultimately fails when this happens due to dependencies not being accessible. Is there an additional step I'm missing to get dependencies to build in the correct order, or are nested dependencies not supported by Eclipse for some reason?

  • 0
    TI__Guru**** 173310 points

    Keith,

    I would expect this to work as long as the dependencies are set up properly for each of those projects, (ie) PAL has dependency on RTOS Platform, HAL has dependency on PAL and RTOS Platform, and so on all the way up to the firmware project.

    Keith Elliott said:
    The issue that I'm seeing is that, while I've ordered the references in the order "Properties->C/C++ General->Paths and Symbols->References" as [Platform, PAL, HAL, Features] for the firmware project, the build order doesn't seem to follow that specification.

    One suggestion here is to specify the dependencies using CCS Project Dependencies (that we have more control over) in place of Project References (that was inherited from standard CDT). Could you give that a try and let us know if it helps?

  • 0 in reply to AartiG
    Intellectual 890 points
    AartiG,

    Thanks for the suggestion. From what I can tell, the CCS Project Dependencies are linked to the CDT Project References. Adding/removing the reference in one spot applies the same change to the other, so the dependency already exists in CCS Project Dependencies.
  • 0 in reply to Keith Elliott
    TI__Guru**** 173310 points

    Could you provide an example of where an "out-of-order" build occurs? If you could save off the output in the CCS build console during one of those builds and send it to us, that might be helpful. Also could you attach screenshots of how the dependencies are set up for each project?

  • 0 in reply to AartiG
    Intellectual 890 points

    I'm attaching a zip file with the screenshots and build output you requested.  Additionally, the zip file also contains the generated makefiles, since I assume that's what's ultimately affected by the "Project References" feature.  I'll PM you the password for the zip file.

    The build output was triggered via a command line call to eclipsec.exe.  It's essentially just an NAnt wrapper that imports all of the projects to a single workspace and then starts a build on the "firmware" project.  Each of the projects have prebuild and postbuild steps that call an NAnt prebuild and postbuild target, respectively.  These targets are very basic file copying so I assume their presence in the build output can be ignored.  Essentially the postbuild publishes files (.lib and .h files) to a globally visible directory and the prebuild pulls the files (.lib and .h) from the projects it's dependent on from that same global directory as well as several autogenerated files.BuildOutput.zip

  • 0 in reply to Keith Elliott
    TI__Guru**** 173310 points

    Keith,

    Thank you for providing the files. We will take a look to see if they are sufficient to tell what is going on or if we would need a reproducible test case.

    I had a couple of questions though to clarify a few things:

    1) Although the console output does show the project builds starting out of order, I'm curious if the errors in project efn01740 (could not open source file "pal/timers.h" ) is related to the build order or not. Is the include path for that header file being passed correctly to the compiler? Is this failure related to dependency build order? 

    2) Since you are using command line builds, I'm curious if the same behavior is seen when building from CCS GUI. Have you tried that or could you give it a try and let us know if the same thing is observed?

  • 0 in reply to AartiG
    Intellectual 890 points
    AartiG,

    Happy to help! Let me know if there's anything else you need from me.

    In response to your questions:

    1) So the efn01740 project is the HAL project, which is dependent on the PAL (am571x) and Platform (sysBios) projects. The PAL (am571x), as part of its post-build steps, copies its public header files to the global directory I mentioned in my previous post. This includes the timers.h header file. The HAL (efn01740) then copies these include files to a local directory that's listed in its project include paths. As an example, "timers.h" is copied to "{GLOBAL_DIR}/pal/timers.h" as the PAL post-build step. "{GLOBAL_DIR}/pal/timers.h" is then copied to "{LOCAL_DIR}/pal/timers.h" as part of the HAL pre-build step. So essentially the file should be there, but it's not because the PAL (am571x) project was not built before the HAL (efn01740) project.

    2) I can confirm that the CCS GUI also builds out of order when attempting to build the "firmware" project.
  • 0 in reply to Keith Elliott
    TI__Guru**** 173310 points

    Keith,

    Without complete test projects to reproduce this I haven't been able to take it very far with my investigations. I have, however, requested a CCS engineer to take a look at this but it may be a few days before we have something to report back. We will keep you posted as soon as we have more information. 

    Thanks for your patience.

  • 0 in reply to AartiG
    TI__Guru**** 173310 points

    Keith,

    I apologize for the delayed reply. An engineer has looked into this and confirmed there is a bug somewhere in CCS that is causing this to happen. Unfortunately we do not have a workaround at the moment, as it is still being investigated. For your reference, the tracking # for the bug is CCSIDE-3064. You can track its status using the SDOWP link in my signature (it may take a few hours from now for it to show up on that page).

    Thanks for your patience, and for bringing this issue to our attention!

  • 0 in reply to AartiG
    Intellectual 890 points
    Thank you for your help!