CODECOMPOSER: CCS Project Makefile Generation Issues

Emily Birch

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: DRV8353

Hi all,

For context, I am setting up an automated embedded build pipeline using Jenkins+LDRA. I have encountered an issue where the source makefiles that are generated for a CCS build are in a strange format for some builds, and this has ramifications for the LDRA build analysis tools. What I need to know, is how to prevent CCS from generating makefiles in this "strange" format.

The problem is best shown by presenting two autogenerated makefiles. These makefiles are both from the same CCS project, same file, same CCS build configuration, but one is manually triggered by myself on the command line and the other is built via Jenkins; both on the same computer. For some inexplicable reason (to me!), the difference in the build environment is producing the strange makefiles. I will label the "strange" makefile as the "jenkins" makefile, and the "normal" makefile as "manual", simply because this is how I have experienced the problem; it is not necessarily because this is a Jenkins related problem. Please see the makefiles below; note that I have removed the include paths for brevity.

"Jenkins" makefile

################################################################################
# Automatically-generated file. Do not edit!
################################################################################

SHELL = cmd.exe

# Each subdirectory must supply rules for building sources it contributes
src/brompton/assistance/%.obj: ../src/brompton/assistance/%.c $(GEN_OPTS) | $(GEN_FILES) $(GEN_MISC_FILES)
@echo 'Building file: "$<"'
@echo 'Invoking: C2000 Compiler'
@echo 'Flags: -v28 -ml -mt --cla_support=cla2 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu0 -O2 --opt_for_speed=2 --fp_mode=relaxed --include_path="<removed include paths for brevity>" --advice:performance=all --define=_F28004x --define=DEBUG --define=_INLINE --define=_FLASH --define=DRV8353_SPI --c11 --c++03 --float_operations_allowed=32 --diag_warning=225 --diag_wrap=off --display_error_number --emit_warnings_as_errors --verbose_diagnostics --gen_func_subsections=on --abi=eabi --preproc_with_compile --preproc_dependency="src/brompton/assistance/$(basename $(<F)).d_raw" --include_path="C:/jenkins_home/workspace/283-implement-jenkins-pipeline_2/brixton-f280049c-application/LDRA/syscfg"'
@echo 'Flags (cont-d): --obj_directory="src/brompton/assistance" $(GEN_OPTS__FLAG)'
$(shell echo -v28 -ml -mt --cla_support=cla2 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu0 -O2 --opt_for_speed=2 --fp_mode=relaxed --include_path="<removed include paths for brevity>" --advice:performance=all --define=_F28004x --define=DEBUG --define=_INLINE --define=_FLASH --define=DRV8353_SPI --c11 --c++03 --float_operations_allowed=32 --diag_warning=225 --diag_wrap=off --display_error_number --emit_warnings_as_errors --verbose_diagnostics --gen_func_subsections=on --abi=eabi --preproc_with_compile --preproc_dependency="src/brompton/assistance/$(basename $(<F)).d_raw" --include_path="C:/jenkins_home/workspace/283-implement-jenkins-pipeline_2/brixton-f280049c-application/LDRA/syscfg" > "src/brompton/assistance/$(basename $(<F))_ccsCompiler.opt")
$(shell echo --obj_directory="src/brompton/assistance" $(GEN_OPTS__FLAG) >> "src/brompton/assistance/$(basename $(<F))_ccsCompiler.opt")
$(shell echo "$<" >> "src/brompton/assistance/$(basename $(<F))_ccsCompiler.opt")
"C:/ti/ccs1031/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/bin/cl2000" -@"src/brompton/assistance/$(basename $(<F))_ccsCompiler.opt"
@echo 'Finished building: "$<"'
@echo ' '

"Manual" Makefile

SHELL = cmd.exe

In the "manual" makefile, we can see that all of the build flags are supplied in the call to the cl2000 compiler for this file. However, in the "jenkins" makefile this is not the case; it just echoes the flags and there are no flags present in the cl2000 compiler call. What I want to know, is what is causing the makefile format to change in the "jenkins" example? I need to have the makefile present all of the compiler arguments on the command line as in the "manual" makefile, as without these flags being present on the command line the LDRA build analysis tool cannot understand how each source file is compiled. I should note that I have only experienced the "strange" makefiles when building under Jenkins; the makefiles are generated normally when performing local builds, even on the same computer using exactly the same versions of CCS and C2000 CGT.

Any insight as to why these makefiles are different or what causes the different formats would be greatly appreciated.

Thanks

over 4 years ago

0 Ki over 4 years ago

TI__Guru**** 467491 points

Hello Emily,

Emily Birch said:
but one is manually triggered by myself on the command line

I assume this is done using the headless project build command?

Emily Birch said:
However, in the "jenkins" makefile this is not the case; it just echoes the flags and there are no flags present in the cl2000 compiler call.

A first glance of that makefile, it looks like the options are piped to an options file ($(basename $(<F))_ccsCompiler.opt) and then the options file is passed to the compiler. This is not necessarily a bad thing in usual circumstances. Options files tend to be used if the number of options passed to the compiler starts to get very large. I believe this to work around an issue on some systems where there is a character limit regarding the complete command string passed to the system console. Are you passing in many include path directories?

In any case, it is interesting that there is a difference in how the makefiles are generated for the same exact project. I am not familiar with Jenkins so I'll need to investigate further.

Thanks

0 Emily Birch over 4 years ago in reply to Ki

Prodigy 110 points

Hi Ki,

Indeed I am performing the CCS project build via the headless commands on the command line.

I see what you mean about the options file, this is useful context to know; good explanation.

We actually managed to find a way to avoid the issue. When the CCS build is executed in the "Jenkins" context, we noticed that the directory containing the CCS project does not match the CCS project name. This is a result of Jenkins automatically creating these directories using the pipeline name in the Jenkins workspace. We renamed the Jenkins pipeline so that the pipeline name would match the CCS project name, and now the makefiles generated by CCS in the "Jenkins" context match those we generate elsewhere. Why this would affect the makefile generation is beyond me!

Thanks

Emily

0 Ki over 4 years ago in reply to Emily Birch

TI__Guru**** 467491 points

Emily Birch said:
We renamed the Jenkins pipeline so that the pipeline name would match the CCS project name, and now the makefiles generated by CCS in the "Jenkins" context match those we generate elsewhere. Why this would affect the makefile generation is beyond me!

It could be that by matching the project name, it reduced the number of characters to be passed to the system console, hence not requiring an options file to be generated. I'm not sure what the character threshold is in regards to triggering an options file to be generated and used but perhaps it was originally near the threshold and not matching the project name via Jenkins required an extra path to be added to the list of options to the compiler, hence increasing the number of characters to be passed to the system console.

For example, in the original jenkins makefile, I see an extra include path that I don't see in the manual makefile:

--include_path="C:/jenkins_home/workspace/283-implement-jenkins-pipeline_2/brixton-f280049c-application/LDRA/syscfg"

In any case, I'm glad you found a solution and thank you for sharing it!

Code Composer Studio™︎

Code Composer Studio forum

CODECOMPOSER: CCS Project Makefile Generation Issues