Creating an eclipse managed make project with MCU10 is easy: Starting the wizard with File > New > Bareboard Project and after a few clicks I have a project. I don’t need to worry about all the files in the project structure, until……..well, until I need to put the files into a VCS.

A VCS (Version Control System) like Subversion of CVS is great: it stores my project and I can track all changes. But one fundamental rule is:

Do not store derived (or generated) files in a VCS.

At this time I need clarity about which files and folders are essential and need to be in the VCS. And which files are generated (or derived) and shall not be the VCS.

A Kinetis Project

Let’s have a look at my Kinetis K70 project in MCU10.2. As the eclipse project view is hiding files, I open the project folder with the Windows Explorer. It shows the following files:

• .settings has settings (sic!) of my project: com.freescale.core.ide.cdt.toolchain.prefs and com.freescale.core.ide.newprojectwizard.prefs. Inspecting these files do not show any critical information. So I do not store that folder in the VCS.
• MK70FX512_INTERNAL_FLASH and MK70FX512_INTERNAL_RAM: these folders contain all the make files and output files. As shown in No Rule to Make Target I do not need them in the VCS.
• Project_Headers: I definitely want that in my VCS.
• Project_Settings: This has the startup code, linker files and debugger configuration files. I need most of that, but will have a detailed look later on.
• Sources: that’s easy: all my sources, so I want that in the VCS.
• .cproject: This file has my project settings: which build tools to be used, which compiler options, and so on. I absolutely need this one in the VCS.
• .cwGeneratedFileSetLog: As the name indicates, this is a log file. It looks this file is used for the Change Wizard (menu Project > Change Device/Connection). As if I do not plan to use the Change Wizard, I usually delete that file right away.
• .project: That’s a small but critical file: this is my master project file and tells eclipse the name of my project and information about the builder used. I need this one in the VCS.
• ReferencedRSESystems.xml: Depending on my MCU10 version this file is named as rseHostSettingsCache.xml in MCU10.1. This file has all the referenced RSE (Remote System Explorer) settings. RSEs are used to store the debug connection information: I need this file in the VCS.
• SaAnalysispointsManager.apconfig: This file has settings for Software Analysis (Trace and Profiling): If I do not want to use that functionality, I can remove that file. It will be regenerated automatically.

With this I have the overview about the top-level. What is missing are the details of the Project_Settings folder:

• *.tcl: These are script files executed by the debugger and specified in the debug configuration: I need them in the VCS.
• *.mem:  This is the memory file used by the debugger and referenced from the debug configuration: definitely needed in the VCS.
• *.launch: this file has the launch and debug configurations: I need this in the VCS.
• *.pemicro: The P&E debug library creates it for OSBDM, OSJTAG or for the Multilinks. The file is recreated if it does not exist, so you can ignore it for the VCS.
• *.lcf: this is the linker configuration file. For S08 and RS08 a different extension *.prm is used. I need to store it in the VCS.

With this, I know I can ignore the files and folders marked in red for my version control system:

If I can ignore the files, this means as well that I can delete them. Especially for passing that project to somebody else. Actually this this is good practice to reduce the archive file size and not to run into the No Rule to Make Target problem.

Processor Expert Projects

If my project is a Processor Expert project, then I need to consider a few extra things:

• ProcessorExpert.pe: This is an XML file with all the Processor Expert settings, and critical to store in the VCS.
• .ProcessorExpert.g_c and .ProcessorExpert.g_x: These files contain cached information about the code generation, and you can ignore them with MCU10.2 (in MCU10.0 or MCU10.1 they are required, otherwise Processor Expert will overwrite ProcessorExpert.c, Event.c and Event.h :-(.
• *.prm, *.lcf:  Normally Processor Expert generates the linker file. An exception to this rule I explain here. Otherwise I can ignore it.

Information from the developers about the *.g_c and *.g_x files:
*.g_x contains information about last code generation in Eclipse client: Toolchain settings, fenerated files list (what has been generated by PE) – used for later files maintanance (like removing unnecessary generated files)

(optionally if code geneartion log enabled), saved information about components settings during last code generation – this is primarily used to detect changes between each code generation (no matter if the project has been saved or not).

*.g_c contains information about last code generation, but generated by Processor Expert core service. It contains info about recent selected project path, recent generated folders, selected CPU derivative, version of used component and its drivers (see usedSrcFiles), etc. this is mainly important if the project is moved to another location or different Processor Expert. Also  used for renaming modules, if component has been renamed.

Target Task Files and Configuration Files

If I use a project for the ColdFire V2 (e.g. MCF52259), then there are two additional files I need to store in the version control system:

• *.ttf: this is the target task framework file, used to flash the application or to perform hardware diagnostics. The Target Tasks View can be used to manage these files.
• *.cfg: Thats the configuration file used by the debugger to initialize the target.

Summary

With this, I know the meaning of all the different files in my project. And I can decide if I need to put a file into Subversion (or any other VCS) or if I can ignore it.

Happy dissecting 🙂