Eclipse Community Forums: C / C++ IDE (CDT) » Keeping language.settings.xml under source control?

Help

Home

Home » Language IDEs » C / C++ IDE (CDT) » Keeping language.settings.xml under source control?

Show: Today's Messages :: Show Polls :: Message Navigator

Keeping language.settings.xml under source control? [message #1720759]

Wed, 20 January 2016 16:59

Vladimir Grishchenko

Messages: 101
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 #1721186 is a reply to message #1720759]

Mon, 25 January 2016 14:59

Marc-André Laperle

Messages: 256
Registered: July 2009

Senior Member

It sounds like env-hash should not be updated (or written at all) when "Store entries in project settings folder" is ticked. I assume that option exist so that projects can more easily be shared (i.e. in source control). Perhaps it would be a good idea to write a bug about that?

Report message to a moderator

Re: Keeping language.settings.xml under source control? [message #1721635 is a reply to message #1721186]

Thu, 28 January 2016 20:06

Andrew Gvozdev

Messages: 257
Registered: July 2009

Senior Member

Marc-Andre Laperle wrote on Mon, 25 January 2016 14:59

It sounds like env-hash should not be updated (or written at all) when "Store entries in project settings folder" is ticked. I assume that option exist so that projects can more easily be shared (i.e. in source control). Perhaps it would be a good idea to write a bug about that?

The main purpose of env-hash is to figure out when you need to rerun scanner discovery. If "(gcc) environment" changes scanner discovery need to be run again. There are several factors that may affect resulting include paths and preprocessor macros and env-hash tries to take them into account. These factors surely will be different on different computers.
I might be wrong but I believe anything in .settings/ folder should be specific to the current project and is not intended to be shared between teams. I recall that .shared/ folder is intended for sharing between teams. That is not supported currently.

Andrew

Report message to a moderator

Re: Keeping language.settings.xml under source control? [message #1721639 is a reply to message #1721635]

Thu, 28 January 2016 20:49

Vladimir Grishchenko

Messages: 101
Registered: July 2009

Senior Member

The .settings folder is generally used to store project-specific settings (as opposed to workspace-wide settings). Often these settings need to be shared across team members for convenience , this is where source control comes handy. I believe the contents of the .settings folder is most definitely meant to be stored under source-control if necessary, after all .settings is not an ignored resource by default - Look under 'Ignored Resources' under Team preferences.

While not arguing the usefulness of tracking environment changes via env-hash, it seems like the calculated env-hash value should be stored somewhere else as it is local configuration specific, project persistent properties come to mind...

Report message to a moderator

Re: Keeping language.settings.xml under source control? [message #1724841 is a reply to message #1721639]

Fri, 26 February 2016 13:26

Alexei Toumantsev

Messages: 2
Registered: February 2016
Location: Scotland

Junior Member

>It sounds like env-hash should not be updated (or written at all) when "Store entries in project settings folder" is ticked.

Has anyone tried this? Was that of any help?

I'm also annoyed with exactly same issue - spurious changes of
.settings\language.settings.xml file.
The project is on SVN, shared by many, we train people to take extra care during a commit and do their best to double check all changes they are committing.
Obviously, people waste their time analysing what's changed in the above-mentioned file, only to see a change of a couple of cryptic numbers.

Report message to a moderator

Re: Keeping language.settings.xml under source control? [message #1725385 is a reply to message #1724841]

Thu, 03 March 2016 08:08

Alexei Toumantsev

Messages: 2
Registered: February 2016
Location: Scotland

Junior Member

Found another thread where the issue has been covered to a certain extent:

https://www.eclipse.org/forums/index.php?t=msg&th=703039&goto=1303960&#msg_1303960

Going to do some experiments with this, time permitting, but I wonder if someone can answer the following off the top of his head:

- what's going to happen if .settings\language.settings.xml is NOT on a version control system? When someone else grabs the project and tries to build - will it not build at all? or will it not even successfully import to Eclipse? or will the file be automagically created during import?

Ta.

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 #1783652 is a reply to message #1772555]

Thu, 15 March 2018 06:27

Denis Ryndine

Messages: 1
Registered: March 2018

Junior Member

Gulam Helbig wrote on Tue, 12 September 2017 21:17

Although the last post is a bit old I was just interested and have tested the last request.
...
So for me it is quit clear not to version this file in the cvs.

Hi,

I wonder, have you tried this with a clean / new workspace?
(one that did not have this same project before).

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: 224
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

Re: Keeping language.settings.xml under source control? [message #1854056 is a reply to message #1847992]

Fri, 29 July 2022 17:17

bud a

Messages: 1
Registered: July 2022

Junior Member

Sorry, I realize that this is a very old post, but this is one of the top results on google for "git eclipse env hash", and I have another solution.
my solution is to have git replace the env-hash value with 0s leaving the rest of the file intact. that way changes to the hash will be ignored but anything else in the file that changes will be committed.

1. add a .gitattributes file to your repository containing

.settings/language.settings.xml filter=eclipse_env_hash

2. add the following to .git/config

[filter "eclipse_env_hash"]
clean = sed 's/env-hash=\"[-,0-9]*\"/env-hash=\"-000000000000000000\"/g'
smudge = cat

Report message to a moderator

Previous Topic:	TM Terminal is slow as molasses on mac os X
Next Topic:	Grouping bits in binary representation of variables

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Oct 06 18:34:55 GMT 2022

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter