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 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.
HTH,
Jonah
Martin
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
