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/TMS320C6678: How to take advantages of both XDCtools and Git when developing a package?

Part Number: TMS320C6678
Other Parts Discussed in Thread: PROCESSOR-SDK-C667X

Tool/software: Code Composer Studio

Packaging is a good stuff, and thanks to XDCtools for bringing packaging to C. But I am confused in some way when I'm learning the RTSC and trying to develop a new package.

Confused Point 1:

As far as I know, a RTSC product like XDCtools itself is also both a repository and a package in XDC's view, because it has package.xdc and package folder in its root, meanwhile there are many packages located in the `packages` directory. Also XDCtools is a RTSC product which can be searched by, added to CCS projects. 

To me, the view of package/repo from XDC is different from the view of package from other programing language, like Rust or Go. Adding a product is more like adding a package to me, but actually I am adding a XDC Repository.

  • Q1:  Does a RTSC product have to be a XDC Repo?
  • Q2: Is there any advantage that a XDC Repo is also a package?

Confused Point 2:

Git submodule is a good way to import or merge different souces into one code base with history tracking. But when I try to use this feature when I tried creating a XDC Repository, I see some obstacles.

For example, I have the following design in mind:

  • SharedPkg0
    • manged by Git.
    • of which codes are to be imported by different XDC Repo
    • xdc package name: team.feat0
    • relative path: ${pkgroot}/team/feat0
  • Repo0
    • mangaed by Git.
    • which will import SharedPkg0
    • already shipped one package named: team.feat1; path: ${reporoot}/team/feat1

In the design listed above, if I want to import SharedPkg0 directly into Repo0 using Git Submodule, I will fail, because the folder team already exists. If I create another folder to store submodule, then I'll break the convention that the path and package name must be consistent.

  • Q3: Any good way to solve this issue? Or how should I change my design?

Q4: Generically, is there any recommend way to take advantages of both XDCtools and Git?

Q5: The RTSC document hasn't been updated for a very long time, and it's not complete. So I am still a little worry about the RTSC and XDC lifecycle and make me think whether should I put some efforts into XDC packaging. Meantime I can find the lastest CCS is shipped with a Node.js executable, does this mean TI will use Node.js and V8 Engine as the core of, maybe next generation of XDCtools? Maybe in future CCS will adopt a NPM package as a new package form?

  • Hi,

    Your thread has been assigned, but due to the holiday week in US, a response might not come until next week.

    Todd
  • This is really an open-ended question that I could answer better if I knew how do you actually use RTSC packaging functionality. Are you just packaging standard C source or you are producing RTSC packages with modules, config scripts and other RTSC features? If you are only using the packaging functionality, what is the main benefit you are getting from it?

    Q1, Q2: The notion of a RTSC product is related to IDEs, and by that I mean CCS. Products have a directory 'eclipse' that contains information about help files, documents, and also package repositories, and then CCS can display documentation, and add your repositories to the package path if a product is used in a project. A RTSC product without any package repositories could exist but I am not sure how useful it would be. Outside of an IDE, a notion of a RTSC product doesn't have any meaning.

    RTSC products are usually not RTSC packages. XDCtools is an exception, and I can't really remember why, but if you look at TI-RTOS, SYS/BIOS, SImplelink SDKs, you'll see that these products do not have package.xdc in their top repositories.

    Q3, Q4: We do have packages that are delivered by multiple repositories, but we don't use Git's submodule functionality, so I don't have any experience to share. What we usually do is to keep a package's main location (in your case team.feat0 in SharedPkg0) in a version control system, and then copy the package to different repositories either using various scripts or our repoman tool that comes with XDCtools. You can find more about repoman here - rtsc.eclipse.org/.../package.html and rtsc.eclipse.org/.../Command_-_xdc.tools.repoman.
     
    Q5: Which document are you referring to? The main source of RTSC documentation is RTSCPedia at rtsc.eclipse.org/.../Main_Page, and we update its pages when needed. It may not be as frequent as it should be, but it's definitely not abandoned.

    I can't really comment much about the future of XDCtools, because I am not in charge of making such decisions. As with any other product, we are always making changes to XDCtools to accomodate customers and that may mean some incremental changes, or scraping it and starting with something new.

    I don't know how much I really answered, but let me know if I missed something or if youhave further questions.

  • Hi Sasha,

    Thank you so much for the detailed reply. Your answer helps a lot.

    I think I will refer to the package design from the QMSS/SPI LLD driver of c667x-pdk shipped with Processor-SDK-c667x, or something like that.
    The c667x-pdk is a repo and LLD driver is a package with only one module(implemented by Settings.xdc), essential build sripts. The module 'Settings' may be a metaonly module affecting only the build process. All the header files are directly used by user like me. And I can see several TI official drivers adopt this design.

    I choose the package design style mentioned above because I can directly create header files with straightfoward interface names and attributes avoiding messing with a lot of generated codes & macros, which also have very long names.
    The benefits I'll get are that I can no more configure the compiler include path & linker search path in my CCS projects.

    But the Git Submodule functionality is still a problem to me. All I want is a automatical way to synchronize codes between different directories. I have to try a different style I guess.