Keeping language.settings.xml under source control? [message #1720759] |
Wed, 20 January 2016 16:59 |
Vladimir Grishchenko Messages: 104 Registered: July 2009 |
Senior Member |
|
|
I'm trying to set up CDT to drive existing cross-compile builds with makefiles using the build output parser and the cross-gcc compiler built-in setting detector. I'm mostly successful but I'd like to keep .settings/language.settings.xml under source control so that anyone who checks out our project will get all provider settings automatically. One minor annoyance is that CDT keeps updating the env-hash attribute of each configuration's <provider class="org.eclipse.cdt.internal.build.crossgcc.CrossGCCBuiltinSpecsDetector" element after the project is checked out into the local workspace resulting in a spurious local change to language.settings.xml that may be confusing to other developers and lead to unnecessary commits. Is it a bad idea to keep language.settings.xml under source control and if not is there anything that can be done to prevent updates to language.settings.xml unless project configuration has actually changed?
[Updated on: Wed, 20 January 2016 17:14] Report message to a moderator
|
|
|
|
|
|
|
|
Re: Keeping language.settings.xml under source control? [message #1772555 is a reply to message #1725385] |
Tue, 12 September 2017 11:17 |
Gulam Helbig Messages: 7 Registered: May 2016 |
Junior Member |
|
|
Although the last post is a bit old I was just interested and have tested the last request.
I deleted the complete .settings folder and opened eclipse.
1. The folder .settings was created automatically with the same content and file content of previous.
2. Build the project and the hex files are also the same compared to each other.
So for me it is quit clear not to version this file in the cvs.
[Updated on: Tue, 12 September 2017 11:19] Report message to a moderator
|
|
|
|
Re: Keeping language.settings.xml under source control? [message #1847992 is a reply to message #1783652] |
Tue, 16 November 2021 14:01 |
John McCabe Messages: 228 Registered: July 2009 |
Senior Member |
|
|
I realise it's been a while since the last post, but I thought my experience would be of interest.
Basically, we started off storing the language.settings.xml files in source control (git) and it was pretty annoying that they showed up as changes every time people wanted to commit, when the only changes were on the env-hash field. We (I) experimented with removing them from git and found that everything works quite normally when they are re-created.
However, I've recently found an issue with one project whereby the indexer messes up in [at least] one project. When I remove the "CDT Managed Build Settings Entries" from the list of "Preprocessor Include Paths, Macros etc." and, instead, set exactly the same items in the "CDT User Setting Entries" provider (such that, when I look at the list of "Includes" in Project Explorer, it is exactly the same list as before!), the indexer works better, although still not great (at least symbols within the same source file get indexed properly!).
In the "Providers" tab, when I check the "Store entries in project settings folder (easing project migration)", the include paths I've configured go into language.settings.xml so, unless I can find another way of 'fixing' the indexing in this case, it may be that I need to share that file through git.
The gist of this, therefore, is that, if you stick with the default settings, there's no need to share language.settings.xml but, if you change anything that affects language.settings.xml (other than the env-hash field), then sharing it via source control appears to be necessary.
Therefore it seems to me that, as other people have suggested, there appears to be some conflict in the use of language.settings.xml; I suspect (as someone else mentioned, I think) that the env-hash stuff should be removed and be stored somewhere in the workspace, not the project folder.
[Updated on: Tue, 16 November 2021 14:55] Report message to a moderator
|
|
|
|
Powered by
FUDForum. Page generated in 0.03475 seconds