CCSTUDIO-THEIA: Inherited project dependencies within workspace??

Part Number: CCSTUDIO-THEIA

I'm working on a C2000 project that includes a lot of static libraries.

In a few cases, either the main project, or some of the static libraries have dependencies on the same static library which have several different build configurations (debug_type1, debug_type2, .., release_type1, release_type2, ..)

On the main project I can easily set the required build configuration for a particular project dependency, but for the static libraries I need to manually change the required build configuration for a particular project dependency, to match the build configuration set in the main project.

I would have expected that during a cascading build, the @active option, would inhiret it's values from the parent project, but unfortunately it does not. 

The @active option appear to only refer to which-ever configuration is set in the GUI at the moment, which makes sense when the project is build independent, but not when it's build as a project dependency - and I guess I understand why.

This means a smarter method is missing, such as an "@inhirit from myproject", where all other projects in the workspace that has a dependency on that library are listed. I believe this would be the most transparent solution, and I would like to propose it as a feature request

At the moment, the only workaround I can think of, is to use a script in the pre-build stage, that user ccs-server to switch the project to the required build configuration, and then always have all project that have that library as a project dependency to use @active ... it's just not very nice.

For an immediate workaround, what options exists to automatically ensure that all project dependencies across the workspace are targeting the same build configuration for a specific project dependency? 

  • Hello,

    This is a known limitation with CCS Theia. There is already a request and plan to bring this behavior back like it existed with CCS Eclipse.

    Thanks

    ki

  • Thank you. It's good to know it's in the pipeline. Do you have a ticket I can vote for it on?

    I thought a quick'n'dirty script was a good workaround, but I've spend hours getting nowhere. :-(

    Can you propose a workaround?

  • This is a known limitation with CCS Theia. There is already a request and plan to bring this behavior back like it existed with CCS Eclipse.

    Actually, after re-reading your post, I realize I was mistaken. There is not a plan for (AFAIK):

    I would have expected that during a cascading build, the @active option, would inhiret it's values from the parent project, but unfortunately it does not. 
    This means a smarter method is missing, such as an "@inhirit from myproject", where all other projects in the workspace that has a dependency on that library are listed. I believe this would be the most transparent solution, and I would like to propose it as a feature request

    I'll discuss with engineering if this is something on the roadmap and something we can implement.

  • Thank you,  

    I really hope it's possible to have something like that implemented.

    An alternative solution is to allow scripts to change the build configuration, similar to DSS - this would open up for a lot of other useful uses, but it seems like a much bigger task.

    Yet another solution could be to ensure CCS reloads modified .metadata files: All my current attempts to script a switch have failed since CCS hold the current Build COnfiguration in RAM - it's possible to trigger the change in the .metadata, but it's not reloaded by CCS, so in order to finish the scripted switch, CCS need to restart. :-(   It should be noted that those attempts are mostly hacks, and I would prefer a more stable (and simpler) interface.

    I'm looking forward to get a status from engineering. and from you.

    All the best.

  • I filed a ticket for this request:

    https://sir.ext.ti.com/jira/browse/EXT_EP-13216

    I still need to follow up regarding a current workaround. I'll update you when I get information.

  • Thank you!

  • I discussed with engineering a bit and they will look into implementing an "inherit" feature as you requested.

    As for an immediate workaround, there is likely not anything at the moment unfortunately. At least nothing much cleaner than what you are already doing.