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.

What does XDC actually produce? Can I throw XDC away and configure SYSBIOS manually by myself while purely use C language?

Other Parts Discussed in Thread: SYSBIOS

I really think modular programming a wonderful idea, and XDC actually helps people do this.

But I am a guy who likes pure development environment which means there is only one kind of language works, such as C/C++. 

I tried to write SYSBIOS applications as normal C runtime supported pieces of code without XDC. I compiled these pieces of code resulted in  many unresolved symbols.

Then I searched TI packages trying to find a proper library containing these symbols, but i failed.

So, now, I ask your genuine experts. 

What does XDC actually produce? Can I throw XDC away and configure SYSBIOS manually by myself while purely use C language?

  • This link describes the content of the files generated by XDCtools. Search for the section "Generating program artifacts". The short answer is that XDCtools generates a C source file and a linker command file, in addition to compiler and linker options added to the corresponding linker command lines. The unresolved symbols you encountered are mostly coming from that generated C file.

    We don't support or recommend trying to build SYS/BIOS apps without using XDCtools. We could generate one version of the generated files, which would represent one possible SYS/BIOS configuration out of many, but we wouldn't be able to offer any help for any further changes, no matter how small, to such a configuration. There is no really point in building the infrastructure to support such a use case, especially because we wouldn't be able to support static instances, which means that one supported configuration wouldn't be very efficient in terms of code size and speed.

    But if you don't mind running the configuration at least once, you can generate the C source and the linker command file, and then change them as you see fit, and compile them on your own. Both of these files are generated in the subdirectory package/cfg and have extensions .c and .xdl. The best way to start is to look at the command lines automatically generated by XDCtools and see what's being built and when. You need to pay attention only to the compiler and linker command lines, because these are the only ones you'll need to replicate. If you are building in CCS, you should turn on verbose output at Project->Properties->CCS Build->XDCtools->Advanced Options, check the option -v. If you are building on the command line set the environment variable XDCOPTIONS to '-v'.
    This is very high-level description of what you would need to do. I probably forgot some details because I never really tried to edit and rebuild the generated C file, but just looking at the generated command lines should give you additional hints. 

  • Thank you very much for spending time on my question. I would try to adopt to xdc and practice more.