• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 54 subscribers
  • Views 897 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.

CCS/PROCESSOR-SDK-AM335X: CCS/GNU compiles *.S files EVEN WHEN EXCLUDED

Christopher Weber
Genius 4995 points
Part Number: PROCESSOR-SDK-AM335X


Tool/software: Code Composer Studio

Hello.

My disdain for this environment grows every day...

This DEFECT is in both CCS 7.2 and CCS 10.

I have a large project with *.c files and *.S files in the same folder.

  1. I right click on the *.c file and "build selected file" ...  It compiles the *.S file (!!!)
  2. I right click on the *.S file and pick "Exclude from build".  Then right click on the *.c file to build it, IT STILL COMPILES THE *.S FILE

Well, I am not posting a massive, company owned project to a global forum...  So I figure I'll pull this into a small example project so I can post it.

  1. I right click on the *.c file...  It compiles the *.S file Just Like it did Above
  2. I right click on the *.S file and pick "Exclude from build".  Then right click on the *.c file, NOW IT DOESN'T BUILD THE *.S FILE

So first of all, why, as in step #1 does it build the *.S file when I tell it to build the *.C file??  I can see that the IDE is invoking the compiler for the *.S file in the "Console" terminal.

Second, why, in two virtually identical projects that create static libs, does the first one CONTINUE TO BUILD THE *.S FILE WHEN TOLD NOT TO, and yet the second one DOES EXCLUDE IT?

This has consumed at least two days until I was able to uncover this defect...

And I STILL cannot find any reason for the differentiation between each of the STEP 2 in the projects.

  • 0
    Genius 4995 points

    I was able to use the Windows "XBOX Game Bar" to record the screen.   But it does NOT show the right click context menu.

    CCS is excluded the FIRST assembler file.  But when I excluded the second file, it still compiled it.

    As this video clip demonstrates.

    www.youtube.com/watch

    Although the context menu doesn't show, what is happening is evident from the file that is highlighted.

  • 0 in reply to Christopher Weber
    TI__Guru**** 471961 points

    Hi Christopher,

    Thanks for posting the video. It is very helpful to see the issue.

    In your video, both the *.c and *.S files have the same name (excluding the file extension of course). This is not supported and would cause all sorts of issues with the build since both files would would result in an object file of the same name being generated after compilation (<file name>.o). Do you only see the issue when the file names are the same (excluding the file extension)?

    Thanks

    ki

  • 0 in reply to Ki
    Genius 4995 points

    Ki,

    The overall package where I discovered this problem is a WolfSSL where they had both *.C and *.S files. 

    I assume this is related to being the same name, but I didn't test.  Putting together that little test project took like 5 minutes.  The code doesn't matter.  This is just the way the compiler reacts  (the source files have identical functions, so it would never link anyway)

    This was massively complicated by:

    • The fact that they had "#includes " that drag in XDC code in the assembler file (only partially protected with #ifdefs...) 
    • The fact that those includes are virtually empty in the TI compiler build path, but loaded with code in the GNU compiler.

    So a TI build was perfect.  Then a GNU build generated 1000's of errors, all in XDC code, all scrolled off the window where I couldn't even see the original command line so didn't know which of the 100's of files in the build caused it.

    One time when I renamed the file (I think it was without doing a "clean"), the IDE complained with something like "file xxx.S which is a dependency of xxx.c is not found"...  I have no idea why it concluded that.

    I can see a need/value in having C code and assembler code of the same name (not here, but in the future).  I can try to work around it, but because it only does this for 'some' files is will create difficulty predicting it's behavior.

    DummyProject.zip

  • 0 in reply to Christopher Weber
    TI__Guru**** 471961 points

    Thanks. The issue looks like it is due to the same file name between the c and S file. Since when you try to compile a either A_Source.c or A_Source.S, the command called is the same:

    gmake" -k -j 8 Test/A_Source.o -O 

    It looks like the build system grabs the first A_Source.* source file it finds. In this case, it is always grabbing A_Source.S.

    When I rename the S files so that it has a different name than the C file, the issue does not occur.

    AFAIK, having the same file name for C and assembly files is not something generally supported by any build system. However, it would be a good idea for CCS to warn the user when there is such a scenario to avoid confusion.

  • 0 in reply to Ki
    Genius 4995 points

    Okay, but I should be able to "exclude from build" any file without it deciding it wants to build it anyway.

    As you say, the same name will generate the same object file, which create problems.  

    But not being able to exclude the file is a bigger problem.

    And I also saw this in CCS 7.2.  I am still bouncing back and forth between them as I try to work out this massive migration to GNU7.3/Bios_6_76/XDC_3_55/NDK 3_61

  • 0 in reply to Christopher Weber
    TI__Guru**** 471961 points

    Christopher Weber said:

    Okay, but I should be able to "exclude from build" any file without it deciding it wants to build it anyway.

    As you say, the same name will generate the same object file, which create problems.  

    But not being able to exclude the file is a bigger problem.

    Basically the same file name for the c and S file is screwing up the build system. I assume that if the file names are different, everything works as expected. This is something we need to improve to guard against this kind of scenario.

  • 0 in reply to Ki
    Genius 4995 points

    Ki,

    I'll mark it as resolved, but it's still a problem if it doesn't exclude when told to.

    If it doesn't exclude a file properly based on the name, it might not work properly in other circumstances.

    (what happens if someone tries to "namespace" their files, as in stack.network.udp.c  and stack.network.tcp.c ...  where does the name comparison stop? )

  • 0 in reply to Christopher Weber
    TI__Guru**** 471961 points

    Christopher Weber said:
    what happens if someone tries to "namespace" their files, as in stack.network.udp.c  and stack.network.tcp.c ...  where does the name comparison stop?

    It would stop with the actual file extension (the *.c). Hence stack.network.udp and stack.network.tcp would be recognized as two different file names