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

[15 knots <fifteenknots505@xxxxxxxxx>]

Am Do., 20. Aug. 2020 um 20:40 Uhr schrieb Jonah Graham
<jonah@xxxxxxxxxxxxxxxx>:
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Thu, 20 Aug 2020 at 14:13, 15 knots <fifteenknots505@xxxxxxxxx> wrote:
>>
>> Am Mi., 19. Aug. 2020 um 21:47 Uhr schrieb Jeff Johnston <jjohnstn@xxxxxxxxxx>:
>>
>> > Core build is relatively young and was an initiative started by Doug to simplify the build mechanism especially in the case where
>> > the build mechanism took care of most things internally (e.g. Makefile, CMake, meson).  It was essentially still a work in progress when Doug left and he started simple
>> > with the intention that others would modify it as needed.  My experience with it was to add meson support and allow Docker Containers to be used as targets.
>>
>> Thank you for this explanation. Will have to look into the meson code
>> to figure out how it supports docker containers.
>>
>> >
>> > Regarding Core build and .cproject, there are no set rules.  It was my understanding that Core build attempted to simplify the myriad of settings and probably why the initial
>> > version hard-coded using the config name.  If the wizard doesn't need to store a setting, then that can be modified.
>>
>> I am planning to improve cmake support. I can see that
>> CBuildConfiguration uses osgi.service.prefs.Preferences to store the
>> project settings. Unfortunately o.o.s.p.Preferences does not allow to
>> store lists or sets of Strings which I need for cmake support. Neither
>> does org.eclipse.core.runtime.preferences.OsgiPreferenceMetadataStore.
>> So I think I am forced to store them in the .cproject somehow.
>>
>
> I would recommend storing new stuff in a new file if a preference file format is insufficient - sort of like language.settings.xml in the .settings

So IIUC you recommend for new code on CDT to *NOT* store settings in
.cproject any longer? Well, I'm fine with that.

> directory. Anything can be stored in the .settings directory, just preferences has a good mechanism.
>
> In addition to what Alexander said, there are three common ways to store in preferences more complicated things:
>
> 1- Single preference with tokens
> 2- Multiple numbered preferences (.e.g pref_0=value0 pref_1=value1 pref_N=2 for an array)
> 3- serialized xml or json
>
> 1 and 3 both are not great for version control as the store lists as a single line making diffs in version control harder than they could be.
Neither is 2): If pref_0=value0 is removed, you will see changes for
pref_1..pref_N in version control instead of just a single deleted
line.
Concerning 3) serialized xml or json: If it would be stored in
*multiple* lines, it would be more VC friendly. AFAIK,  at least Java
property files allow to store multi-line values.

Martin