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.

CCSv5 dependencies not working - header file changes do not trigger build when using the "build all" command. Is this a known bug?

There is a header file in my project named build.h that is included in many of the C files in my project.  The problem is that when I make a change to this header file (for example – changing a conditional compile option) and run “build all”  the compiler says there is “nothing to be done”.   This occurs even though the CCSv5 editor detects and grays out conditionally compiled code in other project files that are affected by the change to the header file. 

Has anyone else seen this behavior?  Do I need to specify dependency information manually for each header file somewhere?

 

 

 

  • Hi Prestor,

    so you get no build errors?  What v5 version do you have? (ie what exact ccs version)  Where is your header file relative to the project and have you included the path as per this wiki?

    http://processors.wiki.ti.com/index.php/Include_paths_and_options

    Can you explain a bit more about your setup and what you do?

    Best Regards,
    Lisa

  • We are using Version: 5.1.1.00028.  I do not get any build errors.  I get a “nothing to be done” message.  If I perform a "clean" then everything builds and the correct build options are included as per the header.  The header file is in the same location as the *.c code and if I edit the *.c files the "build all" command detects that a file has changed and rebuilds the required files. 

    The project that I am working with was imported from an older V3.3 project.  The IDE appears to work well with this one exception (i.e. header files not tracked for edits).  I looked at the link to the wiki you included above and did not see anything done differently from what is currently in the my project. 

    There are two batch files in this project for pre build steps and post build steps.  Could this be affecting things?

  • Hi Prestor,

    it makes sense that things work with doing a clean.

    Would you be able to send us a test case project that shows this behaviour?   Does this only happen then on the imported project?  All v3.3 imports?

    Best Regards,
    Lisa

  • Hi Lisa,

    I just checked an earlier project that I had created prior to using the import function, that compiles the same files and it does not have this problem.  That is any changes to the header files get picked up immediately by the "build all" command.  I stopped using this project because it would only build images that ran while connected to the debugger (i.e. the image did not run standalone).  When I was working on this problem I found that I could import the project with the v3.3 import tool.  The import tool created a project that runs both in the debugger and standalone, but now I realize that it created this dependency bug. 

    I don't know if this would be the case for other v3.3 imports since I only ran the tool on one project.  The version of the project that I started wtih was actually V3.1, but the V3.3 import tool "appeared" to work.

    Do you have any hints of which configuration data I should  compare between my two projects to hone in on the different treatment with respect to header files?

    If not, I will see if I can create a test project for you to look at tomorrow.

    Thank you for your assistance with this.

    Regards,

    Prestor

     

     

     

  • Hi Prestor,

    if you could send a small test project that would be great.  If it was actually a 3.1 project, then the import tool may have had an even harder time with it unfortunately. 

    What do you mean by the newly created project not being able to run stand alone?  Perhaps this is something that can be looked at quickly here too.

    Best Regards,

    Lisa

  • HI Lisa,

    I was able to simplify the project down to 3 source files main.c, cldiags.c and build.h.  I uploaded a file named test_dependencies_ccsv5.zip that contains the project in the directory named test.  The file appears large (10 MB) due to the ccsv5 metadata. you will notice that when you enable and disable the build option in build.h the compiler does not recognize that the file was edited.

    Let me know if you see the problem.

    Regarding the other project that does not run stand alone, what I mean is that it only runs when I download the code with a debugger and run it immediately through the debugger.  If I disconnect the debugger and power cycle the target, the code does not appear to execute.   Perhaps we should focus on the project I just sent you for now though to keep things simpler?

    Thank you once again for your assistance.  I ass ume the file was uploaded since it had a tag saying "uploaded"  I will check this once I submit this updated post.

     

    Regards,

    Prestor

     

  • Hi Prestor,

    I see the same behaviour so thanks for sending that.  Let us look into things here and as soon as there is feedback I will let you know.

    Best Regards,

    Lisa

  • Hi Prestor,

    I have filed a bug for this.  The ID is SDSCM00044103 and you can even track it here.

     

    https://cqweb.ext.ti.com/cqweb/main?command=GenerateMainFrame&service=CQ&schema=SDO-Web&contextid=SDOWP&username=readonly&password=readonly

    So sorry, for now you will have to do the clean and build :  0

    All the best with development.

    Best Regards,
    Lisa

  • Lisa,

    Were you able to confirm that this bug occurs with other improrted legacy projects?   By the way the bug report incorrectly says that CCSv4 was used to import the project.  I don't know if this matters much but the version of code composer I am using is CCSv5. 

     

    Prestor

     

  • Hi Prestor,

    I can run a few more tests, but discussing with a couple colleagues it seems there has been some talk of an issue like this but i think one problem to date was the inability to reproduce it.

    So lets see how this might help.

    Best Regards,

    Lisa

  • FYI - this issue has now been fixed for the upcoming CCSv5.2.1.  The issue was not a result of project migration.  The root cause is a CDT limitation where an incomplete source-file dependency graph is generated when object-files and/or output-file are external to the project directory.  A workaround for it has now been implemented.

    Once you upgrade to CCSv5.2.1, your migrated project will behave as expected - a re-migration is not necessary.

    Thanks,

    - Baltasar

  • We have exactly the same problem.

    Is CCSv5.2.1 already available for download?

    On http://processors.wiki.ti.com/index.php/Download_CCS there is only CCSv5.2.0.

     

  • Hi.  No, v5.2.1 is not yet available.  It is currently planned for July 16th.

    - Baltasar

  • Hi All,

    I use 5.2.1 and the problem is still there. When I change an ".h" file the compiler does not compile all c files that include changed ".h" file. Does anybody have a real solution for this?

    Thank you.

    S. Gataric

  • Hi,

    I've experienced that problem on ccs5.2.1 too and now I migrated to ccs5.5 but the problem is still there.

    My project was created with ccs5.1 (if I remember well); I read that this should not be the problem but I start thinking it is.

    Is there something I can do in .cproject or other setting files?

    Thanks a lot,

    Gianluca

  • BUMP!!

     

    I also have found this problem in a project.... I am running Code Composer Studio Version: 5.5.0.00077.

    It is not only very annoying (from a debugging point of view), but also dangerous (from a development point of view)... If I make a simple change in a header file you expect it to be followed through by the complier and don't tend to question it... If I hadn't noticed a subtle problem with the end product whilst functionally testing it I may have had bad code hitting production !!

    :0(

  • Is this problem fixed.

    I'm getting the problem with CCS 5.4

    If a header file is modified, doing a "Build All" is supposed do an incremental build on all the files in which the modified header file is included. Its not happening.

    I need to clean then build to make the changes in header file effective.

  • I would say that this problem is not fixed (CCS 5.5.0.00077).
    At least with respect to file "* .asm".
    If file "* .h" included in the file "* .asm", then the "build all" does not work correctly.
    Example:

      .cdecls    C, NOLIST, "versions.h"


  • This problem existed since introduction of CCS V4.The problem is that dependencies checking of .h file does not work. If just the .c files are changed, it builds correctly. If .h file are changed it does not, therefore the rebuild all command must be used. I do not use assembler so I do not know if dependency checking on .asm file works correctly.  I do not now what is Total Insanity doing, but it is ridiculous to have such a trivial problem for years and not to fix it. I bet TI blames Eclipse for it...

  • Hi,

    This problem was still seen in CCSV5.5.00077.

    When we can get the bug fix ?

    B&R

    tony

  • Is there any one in TI 's support team can answer this question ?

  • Hi Tony,

    Could you provide the steps to reproduce the problem you are seeing?  Or upload an example project to reproduce it?

    Thanks,

    - Baltasar

  • Hi Baltasar,

    This is a well knownledge issue (pls check the history of this post).

    I tried that if you create a simple c/c++ project, the header change will trigger the related c/c++ code rebuild,

    but in our real complex project( a lot of folders, link folders and header file dependencies), the header file change

    will not trigger any related build at all. 

    B&R

    tony

  • Hi Tony,

    Would you be able to share your project?  Or try to create a more complex example that mimics your production project.  We need to be able to reproduce the problem.

    - Baltasar