• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 236 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: CCS-20 headless build

Lars Stein
Prodigy 50 points
Part Number: CODECOMPOSER

Tool/software:

Hi experts,

currently I'm migrating projects from CCS12 to CCS20.2.0.12.

Building the migrated projects in CCS20 with GUI works as expected.

Unfortunatly the headless/commandline build fails when I build a project which uses the 'CCS_WORKSPACE_DIR' variable.
It seems that the variable is resolved to the standard workspace meta data folder in ".../AppData/Local/Texas Instruments/CCS/.ccs-server/workspaces/...".

Is that correct? I would expect an identical behaviour for the GUI and the headless build.

Best regards
Lars

  • 0
    TI__Guru**** 463291 points

    Hello Lars,

    Lars Stein said:
    Unfortunatly the headless/commandline build fails when I build a project which uses the 'CCS_WORKSPACE_DIR' variable.
    It seems that the variable is resolved to the standard workspace meta data folder in ".../AppData/Local/Texas Instruments/CCS/.ccs-server/workspaces/...".

    This looks like a bug. CCS_WORKSPACE_DIR should be referencing your workspace folder containing your projects, not the workspace metadata folder. How is your project referencing this variable? Is it for a linked file or something used in the build options?

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 50 points

    Hi Ki,

    thanks for the fast response.

    I have a linked folder in my ProjectA:
    folderA ---links to---> ${CCS_WORKSPACE_DIR}/../folder/subfolder/include

    This folder is added to the include search path:
    ${workspace_loc:/${ProjName}/folderA}

    With this configuration the project is successfully build within the GUI. The include path is correctly resolved to:
    -I"(WorkspacePath-1)/folder/subfolder/include"


    The same project fails building on the command line:
    ccs-server-cli -noSplash -workspace "WorkspacePath" -application com.ti.ccs.apps.projectBuild -ccs.projects ProjectA -ccs.configuration Release -ccs.buildType full

    The include path is resolved to:
    -I"C:/Users/username/AppData/Local/Texas Instruments/CCS/.ccs-erver/workspaces/folder/subfolder/include"


    I don't know which behaviour is the correct one but would expect that both ways to build a project should lead to the same result.

    Thanks
    Lars

  • 0 in reply to Lars Stein
    Prodigy 50 points

    Additional info:

    I replaced the include search path by the same link which is used for the linked folder:
    ${CCS_WORKSPACE_DIR}/../folder/subfolder/include

    With this search path the error pattern is identical.
    Building within GUI is successful with correct resolved variable and build from command line fails with wrong resolved variable.

  • 0 in reply to Lars Stein
    TI__Guru**** 463291 points
    Lars Stein said:
    This folder is added to the include search path:
    ${workspace_loc:/${ProjName}/folderA}

    Do not use workspace_loc. The behavior of this variable changed in CCS 20 compared to CCS 12:

    https://software-dl.ti.com/ccs/esd/documents/users_guide_ccs/ccs_faqs.html?highlight=workspace_loc#the-eclipse-workspace-loc-variable-is-not-pointing-to-my-workspace-folder-how-do-i-resolve-this

    Lars Stein said:
    I replaced the include search path by the same link which is used for the linked folder:
    ${CCS_WORKSPACE_DIR}/../folder/subfolder/include

    This *should* work. But I see the same issue as you do - works in IDE but not from command line.

    This is a bug. I filed a ticket for this. Tracking link: https://sir.ext.ti.com/jira/browse/EXT_EP-12677

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 50 points

    Thanks for your answer and the bug tracker ticket. This resolves my question regarding the CCS_WORKSPACE_DIR variable used for the commandline build.

    But now there appeared another question regarding the variable expandtion of workspace_loc:

    I'm aware about the changed behavior of the workspace_loc variable. But currently I'm confused about its effectively mode of operation in our CCS projects.
    As mentioned before I'm working on a complete and faultless migration of our system projects and its dependent projects to CCS20.
    Therefore I have much include paths working with ${workspace_loc:/${ProjName}/...}.

    Currently I can observe that this variable is expanded like the "old" or "CCS12" way. Also it is expanded this way when I do a commandline build.
    Due to this observation I currently do not need to change this variable as it works like before.

    But if I'm checking the list of variables ("Show both user-defined and system variables") in the project properties the "workspace_loc"(String) and also the "WORKSPACE_LOC"(Path) variables link both to the users home directory (the wrong directory for my include paths...). 

    Replacing the workspace_loc to ${CCS_WORKSPACE_DIR:/${ProjName}/...} does not work.


    Can you explain this behavior? Why links this variable to the users home directory like described in the CCS-FAQ and why is it resolved to another location (the real workspace location of my projects)? 

  • +1 in reply to Lars Stein
    TI__Guru**** 463291 points

    I have been experimenting with this and I see some odd behavior. CCS 20 should replace any instances of workspace_loc with CCS_WORKSPACE_LOC. It doesn't seem to always do this. And for the ones it doesn't, workspace_loc can point to different things.

    Let's look at this example in CCS 12:

    workspace_loc in CCS 12 points to the workspace folder location. Entries 2-5 point to the same location. Entry 6 points to the "Debug" subfolder of the path the entry 5 points to.

    Now when this project is imported into CCS 20:

    Note that only entries 2 & 4 had workspace_loc converted to CCS_WORKSPACE_DIR.

    Also note that only entry 5 has workspace_loc pointing to the expected workspace metadata folder.

    This is incorrect and inconsistent behavior. My expectation is in all cases workspace_loc should have been migrated to CCS_WORKSPACE_DIR.

    I filed a bug for this. Tracking link: https://sir.ext.ti.com/jira/browse/EXT_EP-12682

    Thanks

    ki

  • 0 in reply to Ki
    TI__Genius 9345 points

    Hi Lars, Ki,

    Small correction - the behaviour that is described in Ki's reply above is actually the expected behaviour.  The "workspace_loc" dynamic variable is still valid in CCS Theia.  It is more like a function than a variable, because it accepts an argument - a workspace-relative path to a resource.  And it returns the absolute path to that resource in the filesystem.  So something like "${workspace_loc:/myProj/folderA}" is totally fine in CCS Theia, and does not require migration - it would correctly resolve to something like "C:\Users\<uid>\workspace_ccstheia\myProj\folderA".  The only case that requires migration is when "workspace_loc" is used without an argument, i.e. "${workspace_loc}".  This is also still valid, but it's not very useful, because it resolves to the Eclipse workspace, e.g. "C:\Users\<uid>\AppData\Local\Texas Instruments\CCS\.ccs-server\workspaces\f995c650cc20962bd4a75445527ce226", instead of the user workspace, e.g. "C:\Users\<uid>\workspace_ccstheia".  So we migrate only these argument-less occurrences of "${workspace_loc}" to a new variable "${CCS_WORKSPACE_DIR}", which resolves to the user workspace.

    One more thing - users often mix up "${workspace_loc:/myProj/folderA}" and "${workspace_loc}/myProj/folderA".  Notice the subtle difference - the first form passes "/myProj/folderA" as an argument to "workspace_loc" function, while the second form invokes "workspace_loc" with no argument, and then appends "/myProj/folderA" to the return value.  Both these forms would have resulted in the same path in CCS Eclipse for most projects (because Eclipse workspace and user workspace were the same directory).  But in CCS Theia, these two forms result in totally different paths - the first one would expand to something like "C:\Users\<uid>\workspace_ccstheia\myProj\folderA" (which is what the user expects), and the second form would expand to something like "C:\Users\<uid>\AppData\Local\Texas Instruments\CCS\.ccs-server\workspaces\f995c650cc20962bd4a75445527ce226\myProj\folderA" (which is not what the user expects).  So, as mentioned in my first paragraph, the first form is totally fine in CCS Theia and does not require migration.  But the second form would get auto-migrated to "${CCS_WORKSPACE_DIR}/myProj/folderA" (at project import time), in order to give the same behaviour as CCS Eclipse.

    Also, I did reproduce the issue that Lars described originally, where the variable "CCS_WORKSPACE_DIR" incorrectly resolves to the Eclipse workspace (instead of user workspace) when running headless apps.  This bug only affected headless apps, and it is now fixed for the upcoming CCS v20.3.0.

    Baltasar

  • 0 in reply to Baltasar Belyavsky
    TI__Guru**** 463291 points

    Thank you for the clarification!