• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 103 subscribers
  • Views 1400 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.

Project with several libraries: unnecessary link step for libs (Cortex A8, RTSC tools); "--generationOnly" as solution?

Robert Finger
Mastermind 18088 points

Team,

A customer of mine is developing a SYS/BIOS application on Cortex A8 . The main project is using several libraries (subprojects). As SYS/BIOS is used, our XDC tools are used for all compiling the libraries as well. Recompiling the whole project with all libraries takes very very long. For all libraries a link is initiated (lnke8f), even if this would not be needed.

The customer found out that the link for the libraries is skipped if they use the "--generationOnly" option. It has to be added to the XDC expert settings. With this, the compile is much faster (few minutes vs. ~1 hour).

The customer now questions why this option is not selected as default when generating a library. Are there any negative effects that this option could bring?

Thanks,
  Robert

  • 0
    TI__Guru**** 173310 points

    Robert,

    Since this an option to the XDCtools and not the code generation tools, I will move this post to the BIOS forum so the experts there can comment on the effects of this option.

  • 0
    TI__Prodigy 455 points

    Robert,

    The XDCtools integration into CCS doesn't directly support building library projects, but we can work around that. Since the customer's application is large enough to have subprojects, I'd like to recommend a slightly different setup that will help them separate the XDCtools and non-XDCtools parts of their build, and hopefully clean things up.

    Using the "--generationOnly" option on the library projects implies that the customer has included a .cfg file in each library project, and this isn't needed -- there's almost always only one .cfg file for the entire system. The customer is probably only using this as a way to get the generated compiler options (-I paths, -D names) into the library builds. There are no negative consequences to functionality since the .cfg file output for the library files is literally not used, but it's probably slower than needed since multiple .cfg files are being processed and discarded.

    I think the cleanest way to set this is up is to put the .cfg file into its own subproject, a "RTSC configuration". Any project that depends on this using CCS's project dependencies will also automatically inherit the compiler and linker options that the .cfg file generates. Specifically, if the library subproject depends on it, then the library source files will automatically get the include paths to SYS/BIOS etc.

    Here's a screen shot of a test in my workspace. It contains three projects: an executable and two subprojects.

    To create a RTSC configuration project you can do what I did here, which was to use the CCS New Project wizard to create the SYS/BIOS "Task Example (separate config project)" example:

    You can also use the New Project wizard to create a configuration project directly by setting the project output type to "Other..." earlier in the wizard, but it's more work.

    Jon

  • 0 in reply to Jon Rowlands
    Expert 2795 points

    Screenshots no longer works. 

  • 0 in reply to David Luca
    TI__Mastermind 37985 points

    David,
    do you mean the setup described in the answer fails to build projects, or the dialog boxes look different now?

  • 0 in reply to Sasha Slijepcevic
    Expert 2795 points

    The screenshots are not viewable, but the answer was helpful. Thank you.