CCS/TMS320C6678: How to implement XDCscript codes that generates codes right into CCS RTSC projects?

Hi Sasha. Thank you for the reply.

I know about the @CustomHeader attribute and I don't wanna use it because the long main header file is still generated by XDC.

The @Template attribute seems a great idea, but it doesn't work for me. Because my source code are written in C++ with several namespaces, in which the interfaces are not callable from C. I have to create C callable wrapper for those interfaces if I want to use C code.

Any other way to achieve my goal?

I can see some feature in a RTSC project:

• The generated "app_p<target>.c/h" files are located inside a generated package named configPkg.
• The makefile of CCS project itself does not contain any information about the "app_p<target>.c/obj", so the project doesn't have to know about the generated source files.
• The CCS project links with "linker.cmd" which is generated inside package configPkg. And in that linker script, there writes the location of "app_p<target>.obj".

So I guess maybe I can use the same way that to generate a custom package or to add some script into the package configPkg, so that my custom source file generated from template can be compiled inside a package and then be linked with CCS project's other stuffs. But is this method achievable?

I don't understand your proposed solution. You can't really add any extra files to the automatically generated package configPkg, if that's what you meant to do. Also, you already have a package with a metaonly module and a genFile(), so you don't need an additional custom package.
It seems your only problem is how to insert the file generated by genFile() into the CCS project.
From your library package, just before you invoke genFile(), you can find the absolute path to your top project directory in CCS.
You can use Program.buildPackage -rtsc.eclipse.org/.../Program.html to get the name of the main configuration package. You already know it's 'configPkg' but you don't have to hardcode it. Then, you can find the absolute path to the repository for that package http://rtsc.eclipse.org/cdoc-tip/xdc/IPackage.html#package.Repository, and that would be Debug or Release directory. From there, you can go one level up and create your C++ file in the top directory, where CCS should automatically pick it up and build it. Here is how you get to the top directory of your project:
xdc.loadPackage(Program.buildPackage).packageRepository + "/..";

You may want to create an initial C++ file even before you run your template so that CCS will add it to its makefile, and then your template will just keep replacing the content of that file with a new content.

Finally, I have to tell you that this is an unusual usage of XDCtools and I haven't really tried any of that. It may or may not work. Please let me know if you decide to try it and encounter some problems.

Hi, Sasha.

Thank you for your idea, and I tried to generate cpp file directly into CCS project directory. It only works in incremental building, that is, if I build a project from scratch, it fails and then I have to build it again (now becomes incremental). This also means that I have to click 'Build' twice for creating binary file, which makes building work a strange one. So I am not gonna adopt this way.

I guess pre-adding a cpp file in project and use template to replace its content should prevent this problem, but this method let every CCS project to add initial cpp file manually, which makes library not easy to use. So I have to give it up.

But you pointed out that I can use 'xdc.loadPackage(Program.buildPackage).packageRepository + "/.."' to track down the actual project location. It helps me a lot.

So my current solution is:
- the source file is compiled inside library package, which makes it unchangeable to library user in configuration object model.
- provide multiple libraries with different settings.
- user codes use one single header file as entry to access one of the multiple libraries, and that header file includes an intermediate header file that is generated inside CCS project and determines which libraries is actually used according to the cfg model.