Hi folks,
At the last call I had an action to send a note to the list identifying some of the issues with .cproject file as it is used in CDT today.
At today's
CDT Monthly Dev call we did a quick brainstorm to share the main issues with our friends here in the CDT Cloud community.
Here is the extact from the minutes, I hope it is useful to you all.
At the last Eclipse CDT Cloud call the discussion of the use of .cproject was raised. At that meeting Jonah offered to send to cdt-cloud-dev mailing list a summary of the main issues that affect users and ISVs with .cproject files. Here is the result of brainstorming this issue at the CDT monthly call:
- Not stable content
- Negatively affects usability, especially with source control
- Contents of file can change unexpectedly without making any changes in the UI.
- Sometimes the
.cproject stores the ID, and sometimes stored string. The problem is that clicking apply can sometimes flip from one to another
- Too much detail in the file
- The
.cproject file contains som presentation info and not just the setting
- IDs in the
.cproject- The file contains seemingly random numbers added to IDs which makes it harder to edit and understand file contents for users. e.g. the numbers at the end of
<tool id="cdt.managedbuild.tool.gnu.cpp.compiler.exe.release.891378864"[...]
- Mismatch between data container and something else
- Default values are stored in the
.cproject file sometimes.- This means that if a default value is changed in a new version of CDT (or ISV product) that change won’t take effect on the user’s project.
- This happens inconsistently.
- How it handles resource specific configurations
