Thanks for the reply. I fully agree, it doesn’t make sense to store the settings detected by GCCBuiltinSpecsDetector in revision control.
My problem seemed to be caused by a second settings provider for my project. It looks like if there is at least one provider requesting to store its entries
in project settings (the check box in the project properties -> C/C++ General -> Preprocessor Include Paths… is enabled), then all providers are stored in project settings. So as long, as I take proper care of my other providers, I don’t have a problem.
You can try that out with the “CDT User Setting Entries”, where I think sharing settings via project settings would make sense.
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Andrew Gvozdev
Sent: Monday, January 16, 2017 8:38 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] .settings/language.settings.xml meant to be revision controlled?
GCCBuiltinSpecsDetector is intended to detect gcc built-in settings on the local system. Once the environment changes (GCC upgrade for one example) the provider will rerun to capture new settings. Since environment
on individual computers is generally different (or may easily get out of sync) it makes little sense to me to keep captured settings under source control. Even if you manage that the providers will rerun in new environment and overwrite settings from the repository.
To keep the settings along with the hash locally under .metadata/.plugins uncheck "Store entries in project settings folder" in provider options.
On Fri, Jan 13, 2017 at 10:29 AM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Yes, I agree it is a bug to have it as part of the project. It's
underlying usage is still important, so storing it in the workspace
makes sense to me.
Perhaps Andrew Gvozdev can comment further.
In the meantime the env-hash was introduced in the fix for
https://bugs.eclipse.org/bugs/show_bug.cgi?id=382423, although AFAICT
it is actually not 100% related and actually added at the same time,
not because the Cygwin specs provider required it anymore than
previous ones. Since then the idea has been expanded to hash other
parts of the environment, such as the path and modification date of
the compiler and a few other things (see
AbstractBuiltinSpecsDetector.calculateEnvHash()) for details.
Kichwa Coders Ltd.
On 7 January 2017 at 12:14, Elmenthaler, Jens
> Hi all,
> I wonder if there is some guidance whether to put
> .settings/language.settings.xml under revision control or not.
> Looking at the contents, I see indicators to put it under revision control,
> since all developers should share the same settings, and not re-enter them
> every time the project is imported, e.g.:
> - The list of all enabled language settings providers that the
> project requires is stored there.
> - Adding user settings and enabling “Store entries in project
> settings” stores my user setting there.
> On the other hand, there is the GCCBuiltinSpecsDetector with the env-hash
> attribute, whose value depends on the user’s environment. Its value depends
> on the value of the user’s PATH environment variable, and thus sharing is
> not possible.
> I tend to treat everything in the .settings folder to be put under revision
> control. In this case, however, storing the env-hash attribute in
> .settings/language.settings.xml as opposed to
> seems to be a bug.
> Any opinions?
> Greetings, Jens.
> cdt-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit