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.

CODECOMPOSER: Command Line Builds on a Project Converted to TI Clang

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: CCSTUDIO

I have a project which was developed in the TI v20.2.5.LTS toolchain and now migrated to TI Clang v2.1.0.LTS. I also have a script for automated builds which calls this command:

  • eclipsec -noSplash -data <root_dir> -application com.ti.ccstudio.apps.projectBuild -ccs.autoImport -ccs.workspace -ccs.configuration Debug -ccs.buildType full -ccs.listProblems

The command worked perfectly with the TICGT compiler, but after migrating to TI Clang, the command no longer works and has this behavior:

  • If there is a previous build present, I get the error "Program "make" not found in PATH." The tool attempts to call "make clean" instead of "gmake -k -j clean -O" like it does in the GUI.
  • If there is no previous build present, the command does nothing and says "Nothing to build for project"

Compiling on the GUI works without any problems.

  • Additionally I have tried copying the project to a different location and trying the command and it actually worked. Does anyone have any idea why it works in a different location but not in the original location?

  • I should add that the CCS project is part of a Git repository.

    I have tried importing the project into a new workspace and faced somewhat similar issues when using the GUI:

    • If there is no previous build present, the project builds correctly in the GUI.
    • However, if there is a previous build present, the project shows several problems:

    It's like half the project settings are missing.

    I am importing the project using the Git perspective > Import projects.

  • I would import from the CCS Edit perspective and use Project -> Import CCS Projects.

    For those paths that are showing up as invalid are they relative to your project folder.

    Project

    \application\include

    \devices\include

    ...

    What do they look like in your build options?

    Go to the project properties

    Click the link at the bottom to "Hide advanced settings"

    Then go to Build -> Arm Compiler -> Include options in the tree on the left.

    Regards,

    John

  • So I restarted CCS and the problem goes away.

    This is how my paths are configured:

    I'm not sure if you noticed in that image, but I could not access the Arm Compiler tab when I initially imported the project. The settings seem to not be importing correctly initially, but upon restarting the program they become accessible.

    But, the main problem I would like to figure out is the command line one from my initial question. I assume it is similar behavior (CCS command line is not importing the project build settings correctly and is trying to use make like in the GUI image above). Any ideas on how to fix this? Does my command look correct?

  • That is odd.  Even when showing the advanced settings you should have been able to expand "CCS Build" to get to the compiler options.  It does seem like the project did not import properly at first. 

    From the command line I wonder if you split your actions into an import and then the build if that would do the same trick as the restart you are using in the GUI.

    Our best experts on this are out for a couple weeks so I will do my best.

    i.e. first call

    eclipsec -noSplash -data "<workspace_dir>" -application com.ti.ccstudio.apps.projectImport -ccs.location <path> [<options>]

    Then

    eclipsec -noSplash -data "<workspace_dir>" -application com.ti.ccstudio.apps.projectBuild (-ccs.projects <name>) [<options>]

    Regards,

    John

  • This appears to have resolved the issue. Should this behavior be considered a bug in CCS?

  • Fernando,

    Yes I will get out DSS expert to try it out when he gets back but yes if the command now has to be split into 2 commands then it is definitely a bug.  

    Regards,

    John