Extension for preprocessor dependency files given as '.d_raw' in the console window and build log

Paulo,

I am going to need to speak with our CCS build system expert.  I believe that automatic mode is set as those dependency files are needed by the rest of the build.   I don't believe there is anything special about .d_raw files, just CCS is using that extension so that it knows that they are the files it wants.  I am assuming that it then renames them to .d afterwards as that is typically what people are looking for.

Note that I edited this reply after looking closer at my build console

Regards,

John

John,

Thanks for getting back to me.

I will await more information once you have spoken to a build system expert.

To be clear, I am not questioning the need for dependency files, my query relates to the apparent inconsistency between the file extension specified in the option which gets written to console (and build log) and the extension used for the resulting files.

Paulo,

The build expert should be able to confirm things for us.

I tried watching my build config folder while the build is happening and I can see each .d_raw file show up and then disappear and the .d file immediately appear.  

Once we have the information we can look at adding it to the build section of the CCS user's guide.

Regards,

John

JohnS said:

So to workaround this CCS tells the compiler to generate the file with a .d_raw extension, then fixes the issues and renames to .d. 

Is this related to the issue in CCStudio 10.3 generates broken makefiles for GCC?

Thanks, that makes sense.

For one of my files, I have compared the dependency file created when using the ’automatic (default)’ Parser Preprocessing mode with the dependency file created when using the ’manual’ Parser Preprocessing mode and there are some differences.

The fixed dependency file even begins with the line:

# FIXED

I now understand why CCS issues the warning which states that the Parser Preprocessing mode should be set back to 'automatic' for regular builds.

One final thing, is the functionality that you have explained in this thread captured in a TI document which I can reference?

Chester,

That certainly looks to be a similar issue with how the .d is generated.  That thread didn't get to us.  I will try to reproduce on my end as there could be a bug there.

Regards,

John

Paulo,

I am not aware of any documents that currently cover this.  I think we should add it to the build section of the CCS Users Guide.  Likely in this section: https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_project-management.html#build-rebuild-project

I am guessing that you are going a certification/qualification process.  Do you need a formal doc to reference?  If so how soon.  We have a big update of the guide planned for the start of Oct.

Regards,

John

John,

Thanks again for your responses.

In the first instance I will be able to make reference to this thread.

A formal reference is preferable, so I would appreciate if you can arrange for this topic to be included in the update of the user guide planned for October.

Yes, I think it is the same same problem.

I created a dummy project, with 5 files, main.c, file1.c, file2.c, file1.h, file2.h

In subdir_rules.mk, I see this:

"C:/ti/ccs1031/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major-win32/bin/arm-none-eabi-gcc-7.2.1.exe" -c -mcpu=cortex-m4 -march=armv7e-m -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -DPART_TM4C1230D5PM -I"C:/Users/dthompson/workspace_v10/dummyproj1" -I"C:/ti/ccs1031/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major-win32/arm-none-eabi/include" -Og -ffunction-sections -fdata-sections -g -gdwarf-3 -gstrict-dwarf -Wall -specs="nosys.specs" -MMD -MP -MF"$(basename $(<F)).d_raw" -MT"$(@)"  $(GEN_OPTS__FLAG) -o"$@" "$<"

So that is where the '.d_raw' is coming from (-MF is a gcc option to override the preprocessor dependency output filename).

When I run 

"C:\ti\ccs1031\ccs\utils\bin\gmake.exe"  --debug=v clean all

It generates a main.d_raw file that looks like this (looks good!):

main.o: ../main.c ../file1.h ../file2.h

../file1.h:

../file2.h:

When I run 'rebuild project', ccs generates a make.d like this (note the extra '\' after the filenames.  This is what I think breaks the build.):

# FIXED

main.o: ../main.c\ ../file1.h\ ../file2.h

../file1.h:

../file2.h:

So, my feeling is that ccs is breaking the .d_raw files when it converts them to .d.  

Haven't yet found the bit of code which does this, it could be that it is somehow internal to ccs.

Dave,

The code that is doing the .d_raw to .d is inside CCS.

I have a bug filed that is tracking the issue.  https://sir.ext.ti.com/jira/browse/EXT_EP-10391

I will add the extra info from your post to our system.  That should help.

Regards,

John

We are now using a workaround for this:

fix_EXT_EP-10391.ps1:

to enable, add the following to proj properties>build>pre-build steps:

powershell ${BuildDirectory}\..\..\Tools\script_fix_EXT_EP-10391\fix_EXT_EP-10391.ps1

(you may need to change the path to the .ps1 file)

This works in windows.  There's probably a more efficient solution for osx/linux, something like this maybe (not tested):

sed -i  's/\\ / /g' *.d

Caveat - you probably need to ensure you don't have any spaces in any filenames for this workaround to work!

It doesn't seem to work as a post build step.  Possibly the mangling that ccs does happens after the post build steps?

Dave,

I checked and it does happen after the post build steps.

Regards,

John