[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] What exactly is CDT core build?
|
Hi Liviu and all
On 20/08/2020 19:59, Liviu Ionescu 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.
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.
Many Eclipse plugins use the preferences mechanism to store critical
project-related data and expect these preferences to be persisted and
shared via Team Providers such as EGit. Regardless of whether this
constitutes formally correct use of the preferences mechanism, this
usage is widespread and I note that sharing .settings/ is the default
behaviour (at least for EGit). My personal inference is that per-user
data must be stored in the workspace, not the project.
If a plugin needs to reference files or folders outside the workspace, I
would always recommend using platform-level path variables (Preferences
>> General >> Workspace >> Linked Resources) or CDT build variables
(Preferences >> C/C++ >> Build >> Build Variables) at workspace level.
If these references must be on a per-project basis, then a new
preference scope can be defined, combining the API of the existing
project scope with the storage mechanism of the existing instance scope
(workspace metadata).
Regards
John Dallaway
