• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 613 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.

Platform Independent Builds using various RTSC Tools - Linux vs Windows CCSv5

dewilso4
Expert 1215 points

I'm trying to find a way to implement our source control system in order to allow developers running Code Composer on Windows as well as Code Composer on Ubuntu (or Linux in general) to check out and build joint development projects.

For our Windows developers, we have it so that no directories need to be specified in the Window->Preferences->Code Composer->RTSC path, such that from a clean installation of CCSv5, all a developer must do is check out the source tree, add the projects to a new workspace, and build.  In other words, all tool directories and build/environment variables are specified relative to the project root so that no special attention is required with the CCS settings.

However, the XDCTools and CGT are different on Linux systems.  So, specifying relative paths for the tool locations within the project settings does not seem to be platform independent.  We need a way to check what platform a developer is using and specifying the tool locations (i.e. build/environment variables) based on that.

I've referred to the TI wiki on making portable projects ( http://processors.wiki.ti.com/index.php/Portable_Projects ), and one suggestion for specification of the build/environment variables is through a vars.ini file.  Is there possibly a way to go this route for checking the platform and subsequently updating the variables?  The wiki indicates that the vars.ini file will only be read on importing a project, so what happens if a project adds a new tool or changes a tool version?

Thanks, and any help is greatly appreciated!

  • 0
    TI__Guru**** 171519 points

    Hi,

    I am trying to better understand the issue at hand, and I think I need some clarification on a few things:

    dewilso4 said:

    we have it so that no directories need to be specified in the Window->Preferences->Code Composer->RTSC path

    This option sets the default tool used by the workspace, not per project. That does not look like what you want to do, therefore I would suggest you to set these tools per project (right-click on the project --> Properties --> CCS General --> tab Main for compiler or RTSC for BIOS, etc.). This will update the variables ${CG_TOOL_CL}, ${CG_TOOL_ROOT} and ${XDC_CG_ROOT} automatically.

    A similar thing can be done for the Linked Resources (to reference files) and Build Variables (to be passed to the tools) - but this last one is already mentioned on the page you referenced.

    dewilso4 said:

    However, the XDCTools and CGT are different on Linux systems.

    I am a bit confused by that statement. My understanding is this: do you want to set ${CG_TOOL_CL}, ${CG_TOOL_ROOT} and ${XDC_CG_ROOT} as relative paths to the project root? If so, I am not sure if this is more restrictive than letting CCS take care of these variables for you depending on the OS and the original CCS installation place (the project files do not seem to carry hardcoded paths).

    Also, I move projects between Linux and Windows without any compatibility problems (v5.4, v5.5 but I am almost 100% sure that v5.3 was free of problems as well).

    dewilso4 said:

    The wiki indicates that the vars.ini file will only be read on importing a project, so what happens if a project adds a new tool or changes a tool version?

    The variables set by the .ini file are only read during the project import. This file can also be manually imported via the option shown at the page you referenced.

    What I don't understand is: if a developer changes a tool version, the tool path would be updated via the RTSC tab or the Main tab (both under Project Properties --> CCS General), therefore no .ini file should be needed.

    Regards,

    Rafael

     

  • 0 in reply to desouza
    Expert 1215 points

    Thanks for your response, Rafael.

    What I'm trying to accomplish with this exercise is the ability for a new developer to install Code Composer, check out the source tree (which includes the TI tools as well as project source), import the projects into his workspace, and be able to compile. This should ensure bit-identical copies of the binaries across developers' workstations.

    To eliminate the hassle with new installations (and also for when a developer changes a tool version), I'd prefer to not have to navigate through the IDE to specify tool locations (i.e. by choosing project->properties->ccs general, etc...) because in doing so, I believe the tool variables (CG_TOOL_CL, CG_TOOL_ROOT, XDC_CG_ROOT) would be absolute paths.

    Consider the following scenario:

    1.) Developer A and Developer B are working on a given project.

    2.) Developer A decides to use a newer (or different) version of XDC tools.

    3.) Developer A commits the new tool binaries/libraries/includes to source control and specifies XDC_ROOT relative to the project root.

    4.) Now Developer B simply updates his source tree.

    5.) Developer B builds the project and without any knowledge that Developer A even changed the tool version, he still obtains a bit-identical binary.

    6.) What is Developer B is on a Linux machine and Developer A is on a Windows machine?

    I think I've got 1-5 working, but my problem really lies in 6. How can I have tool versions under source control which will work with both Linux and Windows machines?