Re: [cdt-dev] What exactly is CDT core build?

[Torbjörn Svensson <azoff@xxxxxxxxxxxxxxxxxxxxxxxxx>]

On 20/08/2020 21:29, Jonah Graham wrote:
> On Thu, 20 Aug 2020 at 14:59, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:
> 
>>
>>
>>> On 20 Aug 2020, at 21:12, 15 knots <fifteenknots505@xxxxxxxxx> wrote:
>>>
>>> I can see that
>>> CBuildConfiguration uses osgi.service.prefs.Preferences to store the
>>> project settings.
>>
>> Since I don't know the scope of CBuildConfiguration, I might be completely
>> off topic, and in this case disregards my comment, but please be sure you
>> preserve the distinction between configuration and preferences.
>>
>> A configuration is a set of definitions specific to the project. The
>> file(s) used to store it must be portable, in other words it should not
>> store absolute paths or other platform specific definitions, and generally
>> should be valid on all platforms (Windows, macOS, GNU/Linux). Configuration
>> files can be safely stored in repositories.
>>
>> Preferences are definitions specific to a platform. They can include
>> absolute paths and other information specific to the developer or the
>> developer environment. Preferences should not be stored in repositories,
>> since they generally collide with other team member preferences.
>>
> 
> I think that is not the universal definitions in CDT for preferences vs
> configuration. It is complicated by the fact that Preferences is an API as
> well as a concept - more below.
> 
> 
>>
>> As an example, .project and .cproject are configuration files, and should
>> be stored in the repository (assuming they include portable definitions),
>> and the files in the .settings folder should generally not be saved in a
>> repository.
>>
> 
> I think this is an interesting point and I would appreciate some more
> insight on your views on this. The irony of my role is I spend all my time
> in Java land and end up more familiar with JDT as a user than CDT itself.
> 
> I 100% agree that if there is an absolute path in a setting it should not
> (generally) be checked in, equally indexer settings related to performance
> and scalability. But most of what I generally see checked in .settings are
> things like formatter preferences, codan settings, language settings and
> other more minor stuff.
> 
> There are those that advocate that even .cproject/.project should not be
> checked in - but I think this camp is mostly when team members are not all
> using Eclipse CDT.
> 
> Thanks for your insights.
> 
> Jonah


In my experience, I've always included the .settings directory in
GIT/SVN to make sure that the same settings were used for all developers
of the project.

I would like to remind everyone that files that are placed in the
.settings directory does not relate to any build configuration (or
similar concept) and needs to be handled with care.
Why do I say this?
Well, I used to work on a product that placed a file in the .settings
directory that contained some target related settings that appeared to
be fine at that time, but later on, there was a new requirement to
support different targets via different build configurations (managed
build, yes I know, but I still think it's a valid point). This ended up
being a lot messier than it had to be if we had simply avoided the
.settings file to begin with.


Kind regards,
Torbjörn