• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 335 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.

CODECOMPOSER: Workspace definitions in CCS 20.2.0 for CLI builds

Dave Smith
Prodigy 20 points
Part Number: CODECOMPOSER


Tool/software:

Hello Folks -

We are seeing some strange behavior in how our MSP430 project workspace gets recognized by different build environments. We currently have a multi-root workspace with CCS 20.2.0. The individual project directories have project metadata files, but the top-level workspace only contains a .theia-workspace file. Below is a simplified listing of the project layout:

/tmp/workspace
├── BOOTLOADER
│   ├── .ccsproject
│   ├── .cproject
│   ├── .gitignore
│   ├── .launches
│   ├── .project
│   └── .settings
├── SHARED
│   ├── .ccsproject
│   ├── .cproject
│   ├── .gitignore
│   ├── .launches
│   ├── .project
│   └── .settings
├── APP
│   ├── .ccsproject
│   ├── .cproject
│   ├── .gitignore
│   ├── .launches
│   ├── .project
│   └── .settings
└── msp430.theia-workspace

Our development team uses macOS, and they can build either inside the IDE or from the CLI by pointing to the .theia-workspace file using the following command:

ccs-server-cli.sh -workspace /tmp/workspace -application projectBuild -ccs.workspace

Our CI build environment is a Docker container running Ubuntu, and the same command fails to find any projects in the workspace.

# ================================================================================
# [Fri Jun 27 14:44:42 UTC 2025]: CCS headless build starting... 


# ----------------------------------------

# --------------------------------------------------------------------------------
# [Fri Jun 27 14:44:42 UTC 2025]: CCS headless build complete - 0 out of 0 projects have errors

Instead, we need to run importProject on each individual project first.

ccs-server-cli.sh -workspace /tmp/workspace -application projectImport -ccs.location BOOTLOADER
ccs-server-cli.sh -workspace /tmp/workspace -application projectImport -ccs.location SHARED
ccs-server-cli.sh -workspace /tmp/workspace -application projectImport -ccs.location APP

After that the build command succeeds without issue. However, the import commands make no changes to the workspace file system. So I cannot figure out what has changed to allow the build, and therefore what changes we need to make to the workspace to ensure the builds can run immediately in the CI environment without additional importing.

How should we modify our workspace to be more friendly to the CLI builds since it appears the .theia-workspace file is not fully sufficient?

  • 0
    TI__Guru**** 468061 points

    Hello,

    Dave Smith said:
    After that the build command succeeds without issue. However, the import commands make no changes to the workspace file system. So I cannot figure out what has changed to allow the build

    A project import to add the project information to the workspace metadata folder resides in your user directory:

    <USER HOME>\AppData\Local\Texas Instruments\CCS\.ccs-server\workspaces\<workspace id>

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 20 points

    Thanks Ki -

    Do you know why this step is not necessary on other platforms? There we can just target the theia-workspace file and the build succeeds. We never need to run a separate import step.

  • 0 in reply to Dave Smith
    TI__Guru**** 468061 points
    Dave Smith said:
    Do you know why this step is not necessary on other platforms?

    Are the other platforms also CLI-only build environments? Or was the CCS GUI ever used to interact with the workspace folder that these projects reside in? 

  • 0 in reply to Ki
    Prodigy 20 points

    On the other platforms, usage is mixed and it's almost certain that the IDE is used to edit files before a CLI build is attempted.

  • 0 in reply to Dave Smith
    TI__Guru**** 468061 points
    Dave Smith said:
    it's almost certain that the IDE is used to edit files before a CLI build is attempted.

    If the IDE is used then that project was auto-imported to the workspace. This will happen if a folder containing a CCS project folder is opened/added to the IDE. When this happens, CCS IDE will look for any valid CCS projects and "import" it to the workspace. This means that metadata will be created for it in the workspace metadata location.

  • 0 in reply to Ki
    Prodigy 20 points

    Thanks Ki -

    This raises two additional questions:

    1. How does CCS map between the selected project and the internal workspaces (which appear to have directory hashes)? Does it create a new one (and import) every time, or does the internal path somehow map to the provided workspace path?
    2. Is it possible (and practical) for us to provide the same workspace metadata in our project so the CLI builds do not need to explicitly run an import step? Or is this a bad practice (i.e. shouldn't be committed to source control) and we should rely on CCS to generate these as needed? We have this working with an automated import step before each build; it's just adds unnecessary time to each build we do.

    Thanks again!

  • +1 in reply to Dave Smith
    TI__Guru**** 468061 points
    Dave Smith said:
    How does CCS map between the selected project and the internal workspaces (which appear to have directory hashes)? Does it create a new one (and import) every time, or does the internal path somehow map to the provided workspace path?

    It is the latter. Each workspace metadata folder is associated with a folder (general workspace folder) that was opened in the IDE. That hash name is generated based on the full workspace path name (exactly how it comes up with the folder name is some internal detail beyond my knowledge).

    Dave Smith said:
    Is it possible (and practical) for us to provide the same workspace metadata in our project so the CLI builds do not need to explicitly run an import step? Or is this a bad practice (i.e. shouldn't be committed to source control) and we should rely on CCS to generate these as needed?

    It is likely the latter. The workspace metadata is not designed to be portable or shared. It likely has absolute paths in there.

    Dave Smith said:
    We have this working with an automated import step before each build; it's just adds unnecessary time to each build we do.

    I would recommend sticking with this. It is expected that each project is properly imported to the environment.