CODECOMPOSER: Project .out files differ between build machines

Hello,

Legare Smith said:

I have asked Developer3 to zip his entire project up for me to diff with my local directory and only file differences are:
release.out
release.map
makefile
subdir_rules.mk

See below for the actual file diffs. Every source file and .project, .cproject, and .ccsproject are identical. So how/why is his CCS generating a different makefile?! 

All those files you mentioned can also have information specific to the developer's local environment. Such information includes file path information for source and various utilities, workspace location, timestamps, etc. So unless everyone's PC has everything installed in the same exact directories and are using the same username and build at the same exact time, some differences are expected. The files mentioned are all generated files from the build. These files are typically not in version control.

Legare Smith said:

Every source file and .project, .cproject, and .ccsproject are identical.

These files are expected to be persistent. It is these files that should be checked into version control:

https://dev.ti.com/tirex/explore/node?node=A__AFwtNnyed7LJCr63zDn5xw__ccs_devtools__FUz-xrs__LATEST

Thanks

ki

Thank you for the response, Ki. However, the only item recommended by TI to include in the code repository which I was not, is the .settings directory. I added that and requested Developer3 re-clone and build the project, and the results are identical to last time. Are you saying the .out file will be unique to the environment? If that is the case, how can on ever confirm that two build systems are compiling to the same result? I've added a post-build script to convert the .out to a .bin and those are indeed different between systems still as well.

Got it, so it is impossible to ensure build outputs are identical on TI products. There is a chance they can be generated to be the same, which likely involves using he same folder structure for everything involved, but even then there is no guarantee.

Hi,

I invested also quite some time into that kind of an issue: You may have a look here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1095390/tda4vm-absolute-path-built-in-rodata-section-of-ti-kernel-freertos-components/4132380?tisearch=e2e-sitesearch&keymatch=%252520user%25253A351163#4132380

CCS for me turned out to behave questionable, regarding changing settings regarding how a project has to be build. (compiler, linker settings). Sometimes it does not save the changed options which I made in the settings, sometimes only partly.

Overall, I turned away to use CCS as development tool, I only use it to debug my projects. The projects are built now by cmake, which configuration is transparent and checked into git repos. So no more issues that build options can vary between CCS instances. (Hint: I assume CCS also just use cmake to generate makefiles to build the project internally.)

Despite of all that, you have to be aware, that in some libs from TI are C macros used, which embeddeds information of the building machine in your binary. (__FILE__)

Regards,
Thomas

Thomas Dorsch said:

Overall, I turned away to use CCS as development tool, I only use it to debug my projects. The projects are built now by cmake, which configuration is transparent and checked into git repos. So no more issues that build options can vary between CCS instances. (Hint: I assume CCS also just use cmake to generate makefiles to build the project internally.)

Sorry to hear of your frustrations using CCS as a build environment. cmake is a popular environment and there are many who use it to build outside the CCS environment and just use CCS to debug like you are planning. 

CCS does not use cmake under the hood. CDT is used to generate makefiles from the project and then gmake is called:

https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_project-management.html#build-rebuild-project

Thank you Thomas. I may very well go down that path too and your information will be most helpful!